Czym jest OIDC: Dlaczego go potrzebujemy i jak działa

Definicja OpenID Connect (OIDC)#

OpenID Connect (OIDC) to protokół uwierzytelniania tożsamości zbudowany na OAuth 2.0. Podczas gdy OAuth 2.0 zapewnia jedynie autoryzację, OIDC dodaje możliwości uwierzytelniania, oferując bardziej standardowe rozwiązanie dla scenariuszy autoryzacji i uwierzytelniania użytkowników.

Krótko mówiąc: OIDC = Protokół Autoryzacyjny + Uwierzytelnianie Tożsamości.

Dlaczego potrzebujemy OIDC?#

Aby zrozumieć, dlaczego potrzebujemy OIDC, najpierw przeanalizujmy podstawowe pojęcia i przepływ autoryzacji OAuth 2.0 oraz jego ograniczenia w praktycznych zastosowaniach. Poprzez analizę konkretnych scenariuszy zobaczymy, dlaczego potrzebujemy OIDC zamiast OAuth 2.0.

Kluczowe pojęcia i przepływ autoryzacji OAuth 2.0#

OAuth 2.0 (Open Authorization) to protokół autoryzacji, który umożliwia użytkownikom przyznanie aplikacjom trzecich stron dostępu do ich zasobów bez udostępniania swoich danych uwierzytelniających, takich jak nazwy użytkowników i hasła. Obejmuje cztery główne role:

• Właściciel zasobów: Użytkownik, który posiada zasoby
• Serwer zasobów: Serwer przechowujący zasoby użytkownika
• Klient: Aplikacja trzeciej strony żądająca dostępu do zasobów użytkownika
• Serwer autoryzacyjny: Serwer, który weryfikuje tożsamość użytkownika i wydaje tokeny dostępu

Typowy przepływ autoryzacji OAuth 2.0 działa w następujący sposób:

Jak pokazano, OAuth 2.0 głównie obsługuje wydawanie tokenów dostępu dla klientów trzeciej strony, aby uzyskać dostęp do zasobów użytkownika.

Ograniczenia OAuth 2.0#

Protokół OAuth 2.0 skupia się tylko na wydawaniu tokenów dostępu. Serwer zasobów weryfikuje te tokeny i zwraca autoryzowane zasoby. Jednak serwer zasobów nie zna tożsamości użytkownika.

Nie było to znaczącym problemem we wczesnym ekosystemie internetowym.

Jednak wraz z rozwojem platform takich jak Google, Facebook, Twitter i Github, które zaczęły oferować bogate zasoby użytkowników, które stały się wartościowe dla aplikacji trzeciej strony, pojawiły się wyzwania.

Podczas gdy OAuth 2.0 doskonale nadaje się do autoryzacji dostępu aplikacji trzeciej strony do zasobów użytkowników, ma ograniczenia. Typowy scenariusz to: ponieważ informacje o użytkowniku są również zasobem, gdy aplikacje trzeciej strony potrzebują dostępu do podstawowych informacji o użytkowniku, różne platformy (jak Google, Facebook, Twitter) zwracają informacje o użytkowniku w różnych formatach, co stwarza wyzwania dla deweloperów.

OIDC został stworzony, aby rozwiązać te wyzwania.

Role w OIDC#

Aby umożliwić uwierzytelnianie użytkowników na podstawie OAuth 2.0 i rozwiązać jego ograniczenia, OIDC wprowadził trzy role:

• Użytkownik końcowy (EU): Ostateczny użytkownik, odpowiadający właścicielowi zasobów w OAuth 2.0
• Strona zawierająca (RP): Strona zależna, odpowiadająca klientowi w OAuth 2.0
• Dostawca OpenID (OP): Dostawca usług uwierzytelniania tożsamości, odpowiadający serwerowi autoryzacyjnemu i serwerowi zasobów w OAuth 2.0

OP jest rolą kluczową, zapewniając zarówno funkcjonalność autoryzacyjną OAuth 2.0, jak i traktując informacje o użytkowniku jako osobny zasób.

Jak działa OIDC?#

Proces uwierzytelniania OIDC jest podobny do OAuth 2.0, ale ponieważ OP łączy role Serwera Autoryzacyjnego i Serwera Zasobów, zwraca zarówno token dostępu, jak i token ID. Token ID zawiera informacje o tożsamości użytkownika, a RP może zweryfikować tożsamość użytkownika przez walidację tokenu ID.

Typowy przepływ wygląda tak:

To standaryzuje sposób uzyskiwania informacji o użytkowniku na różnych platformach, eliminując potrzebę obsługi przez aplikacje trzeciej strony różnic specyficznych dla platformy.

Token ID (token tożsamości) w OIDC#

Podczas autoryzacji aplikacji trzecich użytkownicy otrzymują od OP zarówno token dostępu OAuth 2.0, jak i token ID w formacie JWT. Ten token ID zawiera informacje o tożsamości użytkownika, takie jak identyfikator użytkownika, nazwa użytkownika, email i awatar. RP może potwierdzić tożsamość użytkownika, weryfikując token ID.

Jako JWT, token ID zawiera standaryzowane roszczenia, w tym te wymagane podstawowe roszczenia:

• iss (Nadawca): Unikalny identyfikator dostawcy OpenID wystawiającego token ID
• sub (Podmiot): Unikalny identyfikator użytkownika
• aud (Odbiorca): Identyfikator aplikacji klienckiej otrzymującej token ID
• exp (Czas wygaśnięcia): Kiedy token ID wygasa
• iat (Wystawiony o): Kiedy token ID został wystawiony

Punkt końcowy userinfo#

Punkt końcowy UserInfo to standaryzowane API HTTP dostarczane przez OP do uzyskiwania informacji o uwierzytelnionym użytkowniku. Wysyłając żądania GET lub POST z tokenem dostępu do tego punktu końcowego, możesz otrzymać informacje o użytkowniku w formacie JSON. Zwrócone dane zawierają standaryzowane pola, takie jak unikalny identyfikator użytkownika (sub), nazwa użytkownika (name), email i zdjęcie.

Proces uzyskiwania informacji o użytkowniku postępuje według tego samego schematu co uzyskiwanie dostępu do chronionych zasobów w OAuth 2.0. Zazwyczaj informacje o użytkowniku uzyskane z punktu końcowego userinfo są bardziej rozbudowane niż te w tokenie ID, ponieważ token ID służy przede wszystkim do uwierzytelniania tożsamości i podstawowych informacji o użytkowniku.

Pamiętaj, że informacje o użytkowniku, które otrzymujesz z punktu końcowego userinfo, zależą od żądanych zakresów i uprawnień przyznanych podczas autoryzacji.

Zakresy w OIDC#

Zakresy w OIDC definiują, jakie informacje o użytkowniku RP może uzyskać. OIDC definiuje standardowe zakresy, a zakres openid jest obowiązkowy w procesach uwierzytelniania OIDC.

Typowe standardowe zakresy obejmują:

• openid: Wskazuje żądanie uwierzytelniania OIDC
• profile: Podstawowe informacje o użytkowniku, takie jak imię i awatar
• email: Informacje o emailu użytkownika
• phone: Numer telefonu użytkownika
• address: Informacje adresowe użytkownika

Różne zakresy zwracają różne informacje o użytkowniku. Na przykład, żądanie openid profile email zwraca podstawowe informacje o użytkowniku i email w tokenie ID i Userinfo, podczas gdy openid profile email phone address obejmuje także numer telefonu i informacje adresowe.

Zarządzanie tożsamością na podstawie OIDC#

OIDC nie jest tylko protokołem uwierzytelniania; to potężne narzędzie do budowy elastycznych, skalowalnych systemów zarządzania tożsamością. Dodając warstwę uwierzytelniania do OAuth 2.0, standaryzując zasoby informacji o użytkowniku i tworząc podstawy do rozszerzonych funkcji zarządzania tożsamością, OIDC umożliwia różne scenariusze zarządzania tożsamością:

• Jednokrotne logowanie (SSO): OIDC naturalnie wspiera SSO poprzez rozszerzone informacje o sesji użytkownika, umożliwiając jednolite zarządzanie stanem logowania i współdzielenie tożsamości między aplikacjami
• Zarządzanie strukturą organizacyjną: Rozszerzone informacje o organizacji użytkownika mogą zarządzać złożonymi strukturami organizacyjnymi, w tym hierarchiami działów i relacjami grup użytkowników
• Zarządzanie uprawnieniami: Rozszerzone atrybuty uprawnień użytkownika umożliwiają drobiazgową kontrolę dostępu do zasobów, w tym informacje o rolach i konfigurację polityki uprawnień

Elastyczność OIDC dostosowuje się do ewoluujących potrzeb zarządzania tożsamością. Wiele systemów zarządzania tożsamością opiera się na OIDC, takich jak Logto, który zapewnia funkcje SSO, zarządzanie organizacją i zarządzanie uprawnieniami.