Zrozum IAM, OAuth, OpenID Connect, SAML, SSO i JWT w jednym artykule

Dziedzina zarządzania tożsamością i dostępem (IAM) stała się w ostatnich latach bardziej złożona. Skomplikowane terminy, takie jak OAuth, OpenID Connect (OIDC), SAML, SSO i JWT, są często używane, ale co one oznaczają? Jak one współpracują? Pozwólmy sobie zgłębić te pojęcia i ramowe struktury, aby uczynić je bardziej zrozumiałymi i praktycznymi.

Co to jest IAM?#

Zarządzanie tożsamością i dostępem (IAM) to szeroki koncepcja obejmująca zarządzanie cyfrowymi tożsamościami oraz wdrażanie kontroli dostępu. Wspomniane wcześniej ramowe struktury i protokoły wchodzą w skład IAM, każdy z nich adresuje specyficzne wyzwania w tej dziedzinie.

W istocie, IAM dotyczy:

• Tożsamości: Cyfrowa reprezentacja użytkownika, usługi lub urządzenia. Tożsamość zazwyczaj zawiera atrybuty, takie jak imię, e-mail, role itp., aby opisać jednostkę.
• Dostępu: Zdolność do interakcji z zasobami, wykonywania działań lub korzystania z usług. Dostęp definiuje, jakie działania mogą być wykonywane na jakich zasobach.

Na powyższym diagramie użytkownik (tożsamość) chce wykonać żądanie GET do API (zasób). Atrybuty użytkownika - imię, e-mail i rola - opisują tożsamość.

Autentykacja vs. autoryzacja#

Autentykacja i autoryzacja często pojawiają się razem w dyskusjach o IAM. Wyjaśnijmy ich definicje:

• Autentykacja: Proces weryfikacji własności tożsamości. Odpowiada na pytanie: "Którą tożsamość posiadasz?"
• Autoryzacja: Proces określania, jakie działania może wykonać uwierzytelniona tożsamość na zasobie. Odpowiada na pytanie: "Co możesz zrobić?"

W wcześniejszym przykładzie:

• Zanim użytkownik (tożsamość) może wykonać jakiekolwiek działania, musi przejść proces autentykacji.
• Po autentykacji system musi określić, czy użytkownik może wykonać żądanie GET (działanie) do API (zasób), tj. ukończyć proces autoryzacji.

---

Uzbrojeni w tę podstawową wiedzę, rozjaśnijmy inne akronimy i protokoły.

OAuth#

OAuth 2.0, często nazywany OAuth, jest ramową strukturą autoryzacji, która umożliwia aplikacji dostęp do chronionych zasobów w innej aplikacji (zwykle w imieniu użytkownika).

Na przykład, wyobraź sobie, że masz aplikację webową o nazwie MyApp, która chce uzyskać dostęp do Dysku Google użytkownika. Zamiast prosić użytkownika o udostępnienie jego danych logowania do Dysku Google, MyApp może użyć OAuth 2.0, aby poprosić o pozwolenie (autoryzację) od Google na dostęp do Dysku użytkownika.

Oto uproszczony diagram przedstawiający przepływ OAuth:

W tym przepływie:

• MyApp jest klientem (tożsamość) proszącym o dostęp do Dysku Google (zasób).
• Użytkownik (właściciel zasobu) udziela MyApp upoważnienia w kroku 6, kończąc proces autoryzacji.

Kluczowym elementem w OAuth 2.0 jest token dostępu, którego klient używa do wykazania autoryzacji użytkownika na dostęp do zasobów. Aby dowiedzieć się więcej, zobacz Token dostępu.

OpenID Connect (OIDC)#

OpenID Connect (OIDC) jest warstwą autentykacji, zbudowaną na bazie OAuth 2.0. Dodaje funkcje specyficzne dla autentykacji, takie jak tokeny ID i punkt końcowy UserInfo, co sprawia, że jest odpowiedni zarówno do autentykacji, jak i autoryzacji.

Jeśli wrócimy do przepływu OAuth, dodanie OIDC wprowadza token ID. Ten token zawiera informacje o uwierzytelnionym użytkowniku i umożliwia MyApp zweryfikowanie tożsamości użytkownika.

Przykładowa sytuacja: "Zaloguj się przez Google"#

Zmieńmy przykład. Jeśli MyApp chce, aby użytkownicy mogli się zalogować za pomocą swoich kont Google, cel przenosi się na autentykację, a nie na dostęp do zasobów. W tym przypadku, OIDC jest lepszym wyborem. Oto jak wygląda przepływ OIDC:

Kluczowa różnica: Oprócz tokenu dostępu, OIDC dostarcza token ID, co pozwala MyApp na autentykację użytkownika bez potrzeby stosowania dodatkowych próśb.

OIDC dzieli definicje granty OAuth 2.0, zapewniając zgodność i spójność między obiema ramowymi strukturami.

SAML#

Język Zabezpieczeń Asercji (SAML) jest opartą na XML ramą do wymiany danych autentykacji i autoryzacji między stronami. SAML, wprowadzony we wczesnych latach 2000-tych, stał się szeroko stosowany w środowiskach przedsiębiorstw.

Jak SAML porównuje się do OIDC?#

SAML i OIDC są funkcjonalnie podobne, ale różnią się w szczegółach implementacyjnych:

• SAML: Używa asercji opartych na XML, często uważany jest za bardziej złożony.
• OIDC: Korzysta z JSON i JWT, sprawiając, że jest lżejszy i bardziej przyjazny dla programistów.

Współczesne aplikacje często preferują OIDC za jego prostotę i elastyczność, ale SAML nadal pozostaje powszechny w starszych systemach i zastosowaniach przedsiębiorstwach.

Jedno logowanie (SSO)#

Jedno logowanie (SSO) jest schematem autentykacji, który umożliwia użytkownikom dostęp do wielu aplikacji i usług z jedną parą danych logowania. Zamiast logować się do każdej aplikacji osobno, użytkownik loguje się raz i uzyskuje dostęp do wszystkich połączonych systemów.

Jak działa SSO?#

SSO polega na centralnym dostawcy tożsamości (IdP), który zarządza tożsamościami użytkowników. IdP autentykuje użytkownika i zapewnia usługi takie jak autentykacja i autoryzacja dla połączonych aplikacji.

IdP może używać protokołów takich jak OIDC, OAuth 2.0, SAML czy innych do zapewnienia tych usług. Jeden IdP może obsługiwać wiele protokołów, aby zaspokoić różnorodne potrzeby różnych aplikacji.

Przykład SSO oparty na OIDC#

Zobaczmy przykład SSO opartego na OIDC:

W tym przepływie użytkownik loguje się do IdP raz i jest uwierzytelniony w różnych aplikacjach (AppA i AppB).

Enterprise SSO#

Chociaż SSO jest szerokim pojęciem, możesz również spotkać się z terminem enterprise SSO, który odnosi się do specyficznego rodzaju SSO zaprojektowanego dla środowisk przedsiębiorstw (zazwyczaj dla pracowników i partnerów).

Kiedy klient prosi o SSO dla Twojej aplikacji, ważne jest sprecyzowanie ich potrzeb oraz protokołów, które używają. W większości przypadków oznacza to, że dla określonych domen e-mail chcą, aby Twoja aplikacja przekierowywała użytkowników do ich IdP (który implementuje enterprise SSO) w celu autentykacji.

Przykład: dodawanie dostawcy enterprise SSO#

Oto uproszczony przykład integracji dostawcy enterprise SSO (Banana) z Twoją aplikacją (MyApp):

JWT#

JSON Web Token (JWT) jest otwartym standardem zdefiniowanym w RFC 7519, który umożliwia bezpieczną komunikację między dwiema stronami. Jest standardowym formatem dla tokenów ID w OIDC i jest szeroko używany dla tokenów dostępu OAuth 2.0.

Oto kluczowe cechy JWT:

• Kompaktowy: JWT są obiektami JSON zakodowanymi w kompaktowym formacie, co czyni je łatwymi do przesyłania i przechowywania.
• Samodzielne: JWT zawierają wszystkie potrzebne informacje o użytkowniku i samym tokenie.
• Weryfikowalne i szyfrowalne: JWT mogą być podpisane i zaszyfrowane w celu zapewnienia integralności danych i poufności.

Typowy JWT wygląda tak:

Ten JWT składa się z trzech części oddzielonych kropkami:

• Nagłówek: Zawiera metadane o tokenie, takie jak typ tokenu i algorytm podpisu.
• Ładunek: Zawiera informacje o tożsamości i samym tokenie.
• Podpis: Weryfikuje integralność tokenu.

Zarówno nagłówek, jak i ładunek są obiektami JSON zakodowanymi w base64. JWT powyżej można zdekodować w następujący sposób:

Dzięki JWT, klient może zdekodować token i wyciągnąć informacje o użytkowniku bez potrzeby dodatkowych żądań do dostawcy tożsamości. Aby dowiedzieć się więcej o JWT, odwiedź JSON Web Token (JWT).

Podsumowanie#

Pokryliśmy wiele tematów w tym artykule. Podsumujmy kluczowe punkty na przykładzie:

Wyobraź sobie, że masz aplikację webową, AppA, która wymaga rozwiązania zarządzania tożsamością i dostępem (IAM). Wybierasz Logto, dostawcę tożsamości, który używa OpenID Connect (OIDC) do autentykacji. Ponieważ OIDC jest zbudowany na bazie OAuth 2.0, Logto wspiera również autoryzację dla twojej aplikacji.

Aby zmniejszyć trudności dla użytkowników, włączasz opcję "Zaloguj się przez Google" w Logto. Używa to OAuth 2.0 do wymiany danych autoryzacyjnych i informacji o użytkowniku między Logto a Google.

Po zalogowaniu się użytkownika do AppA przez Logto, AppA otrzymuje token ID, który jest JSON Web Token (JWT) zawierającym informacje o użytkowniku.

Gdy twoja firma rośnie, uruchamiasz nową aplikację, AppB, która także potrzebuje autentykacji użytkowników. Ponieważ Logto jest już skonfigurowany, możesz ponownie użyć tego samego przepływu autentykacji dla AppB. Twoi użytkownicy mogą teraz logować się zarówno do AppA, jak i AppB za pomocą jednego zestawu danych logowania, co jest znane jako jedno logowanie (SSO).

Później partner biznesowy prosi cię o połączenie ich systemu enterprise SSO, który używa Security Assertion Markup Language (SAML). Dowiadujesz się, że Logto wspiera połączenia SAML, więc konfigurujesz połączenie między Logto a systemem SSO partnera. Teraz użytkownicy z organizacji partnera mogą również logować się do AppA i AppB, używając swoich istniejących danych logowania.

---

Mam nadzieję, że ten artykuł wyjaśnił ci te pojęcia. Aby uzyskać bardziej szczegółowe wyjaśnienia i przykłady, sprawdź Auth Wiki. Jeśli szukasz rozwiązania IAM dla swojej aplikacji, rozważ użycie zarządzanej usługi, takiej jak Logto, aby zaoszczędzić czas i wysiłek.