Główną różnicą między OAuth a OpenID Connect jest to, że OAuth jest frameworkiem służącym do autoryzacji, podczas gdy OpenID Connect to warstwa tożsamości nałożona na OAuth w celu uwierzytelniania. Oznacza to, że OpenID Connect udostępnia informacje o zalogowanym użytkowniku, takie jak imię i nazwisko, adres e-mail, zdjęcie profilowe itp., podczas gdy OAuth zapewnia dostęp do zasobów użytkownika, takich jak zdjęcia, kontakty, pliki itp.
OAuth vs. OpenID Connect: Jaka jest różnica?
OAuth doskonale sprawdza się w przypadku dostępu delegowanego. Natomiast OpenID Connect idealnie nadaje się do logowania użytkowników.
OAuth 2.0 koncentruje się na autoryzacji. Umożliwia aplikacjom zewnętrznym dostęp do określonych zasobów (takich jak Dysk Google czy kalendarz) bez konieczności podawania hasła. Zamiast tego użytkownik udziela zgody, a aplikacja otrzymuje token dostępu, który pozwala jej działać w imieniu użytkownika w określonych granicach.
OpenID Connect (OIDC) bazuje na OAuth 2.0, dodając uwierzytelnianie. Informuje aplikację o Twojej tożsamości, wydając token identyfikacyjny zawierający zweryfikowane dane, takie jak imię i nazwisko, adres e-mail oraz zdjęcie profilowe. Umożliwia to logowanie, dzięki czemu aplikacja może nawiązać sesję i spersonalizować Twoje doświadczenie.
OpenID Connect i OAuth: wyjaśnienie różnic
Aby zilustrować różnicę pomiędzy OAuth i OIDC, posłużmy się przykładem aplikacji zewnętrznej, która chce uzyskać dostęp do konta Google użytkownika. Dzięki OAuth aplikacja może poprosić użytkownika o zgodę na dostęp do określonych obszarów jego konta Google, takich jak Gmail, Dysk Google lub Zdjęcia Google. Użytkownik może przyznać lub odmówić tych uprawnień, a aplikacja może następnie użyć tokena dostępu, aby uzyskać dostęp do autoryzowanych zasobów w imieniu użytkownika.
Dzięki OpenID Connect aplikacja może również poprosić Google o token identyfikacyjny, który zawiera informacje o tożsamości użytkownika, takie jak imię i nazwisko, adres e-mail, zdjęcie profilowe itp. Aplikacja może użyć tego tokenu identyfikacyjnego do weryfikacji tożsamości użytkownika i wyświetlenia jego informacji w interfejsie aplikacji. Aplikacja może również użyć tokenu identyfikacyjnego do ustanowienia sesji logowania dla użytkownika, dzięki czemu nie musi on ponownie wprowadzać swoich danych uwierzytelniających.
OpenID Connect kontra OAuth: tabela różnic
Poniższa tabela zawiera podsumowanie różnic między OpenID Connect a OAuth:
| Aspekt | OpenID Connect | OAuth |
|---|---|---|
| Cel | Uwierzytelnianie | Autoryzacja |
| Typ tokena | Token ID (ID token) | Token dostępu (Access token) |
| Format tokena | JWT (JSON Web Token) | JWT lub inny format |
| Informacje o użytkowniku | Dostarczane przez token ID | Nie są zawarte w tokenie dostępu |
| Logowanie użytkownika | Obsługiwane dzięki tokenowi ID | Nieobsługiwane przez token dostępu |
| Sesja użytkownika | Obsługiwana przez token ID | Nieobsługiwana przez token dostępu |
| Wylogowanie użytkownika | Obsługiwane przez token ID | Nieobsługiwane przez token dostępu |
| Zakresy | Standardowe, zdefiniowane przez OpenID Connect | Określane przez serwer zasobów (resource server) |
| Odnajdywanie punktów końcowych | Obsługiwane przez OpenID Connect | Nieobsługiwane przez OAuth |
Podobieństwa
OpenID Connect i OAuth opierają się na tym samym protokole bazowym: OAuth 2.0. OAuth 2.0 to struktura delegowania, która pozwala aplikacjom zewnętrznym działać w imieniu użytkownika, bez konieczności udostępniania aplikacji swoich danych uwierzytelniających. OAuth 2.0 definiuje cztery role: właściciela zasobu (użytkownika), serwera zasobów (dostawcy zasobów), klienta (aplikacji zewnętrznej) i serwera autoryzacji (dostawcy tokenów dostępu).
OpenID Connect opiera się na OAuth 2.0 i wykorzystuje dodatkowy token JSON Web Token (JWT), zwany tokenem identyfikacyjnym, w celu ujednolicenia niektórych aspektów, które OAuth 2.0 pozostawia do wyboru, takich jak zakresy i wykrywanie punktów końcowych. OpenID Connect definiuje również piątą rolę: użytkownika końcowego (osoby zalogowanej).
Zarówno OpenID Connect, jak i OAuth wykorzystują podobny proces do uzyskiwania tokenów z serwera autoryzacji. Proces ten składa się z czterech kroków:
- Klient wysyła żądanie do serwera autoryzacji, prosząc o zezwolenie na dostęp do określonych zasobów lub informacji w imieniu użytkownika.
- Serwer autoryzacji przekierowuje użytkownika na stronę logowania, gdzie wprowadza on swoje dane uwierzytelniające i wyraża zgodę na żądane uprawnienia.
- Serwer autoryzacji przekierowuje użytkownika z powrotem do klienta wraz z kodem autoryzacji.
- Klient wymienia kod autoryzacji na token dostępu i opcjonalnie token identyfikacyjny z serwera autoryzacji.
Token dostępu i token identyfikacyjny to tokeny JWT, które zawierają oświadczenia informcacje o użytkowniku i autoryzacji. Klient może użyć tych tokenów do uzyskania dostępu do zasobów lub informacji z serwera zasobów lub do weryfikacji tożsamości użytkownika.
OAuth 2.1 vs. OIDC: Jak OAuth 2.1 wzmacnia OpenID Connect
OAuth 2.1 to udoskonalenie OAuth 2.0, skoncentrowane na bezpieczeństwie. Choć nie jest to całkowita przebudowa, konsoliduje podstawowe najlepsze praktyki w jedną, bardziej przejrzystą specyfikację.
OpenID Connect (OIDC) opiera się na OAuth w swoich podstawowych przepływach uwierzytelniania. Właśnie dlatego OAuth 2.1 ma znaczenie. Nie dlatego, że OAuth 2.1 zmienia cel OIDC, ale dlatego, że podnosi poziom bezpieczeństwa wszystkich implementacji OIDC zbudowanych na nim.
Najważniejsze udoskonalenia obejmują:
- PKCE jest wymagane dla wszystkich przepływów kodu autoryzacji, eliminując typowy wektor ataku.
- Usunięte zostały przestarzałe, niebezpieczne przepływy, takie jak domyślne hasła i hasła właściciela zasobu, co ogranicza ryzyko nadużyć.
- Identyfikatory URI przekierowań muszą być dokładnie takie same, co zapobiega podatnościom typu „otwarte przekierowania”.
- Zaleca się rotację tokenów odświeżania, co ogranicza skutki kradzieży i zmniejsza ryzyko ataków typu replay.
Wszystkie te ulepszenia oznaczają, że każda implementacja OIDC (zwłaszcza te wykorzystujące przepływy OAuth) opiera się na silniejszych i bezpieczniejszych elementach składowych.
Szukasz dostawcy FIDO MFA?
Chroń użytkowników Active Directory i Entra ID przed hakerami przy użyciu odpornych na phishing kluczy FIDO.
Którą opcję wybrać?
OpenID Connect i OAuth mają różne zalety w zależności od tego, jakiego rodzaju funkcjonalności lub zabezpieczeń potrzebujesz dla swojej aplikacji.
- OpenID Connect jest korzystny, jeśli potrzebujesz:
- Uwierzytelniać użytkowników w wielu aplikacjach lub domenach za pomocą jednego logowania (logowanie jednokrotne).
- Weryfikować tożsamość użytkowników za pomocą zaufanego dostawcy (uwierzytelnianie federacyjne).
- Wyświetlać informacje o użytkownikach w interfejsie aplikacji (profil użytkownika).
- Zarządzać sesjami i wylogowaniami użytkowników (zarządzanie sesjami).
- OAuth jest korzystny, jeśli potrzebujesz:
- Uzyskiwać dostęp do zasobów lub danych użytkowników od różnych dostawców (autoryzacja międzydomenowa).
- Delegować uprawnienia użytkowników do aplikacji zewnętrznych bez udostępniania ich danych uwierzytelniających (bezpieczne delegowanie).
- Kontrolować poziomy i zakresy dostępu użytkowników (precyzyjna autoryzacja).
W praktyce wiele organizacji korzysta z obu standardów jednocześnie: OpenID Connect do uwierzytelniania użytkowników, a OAuth 2.0 do obsługi przepływów autoryzacji. Jeśli chcesz scentralizować ten model i włączyć MFA bez implementowania logiki drugiego składnika w każdej aplikacji osobno, sprawdź rozwiązanie Rublon Identity Bridge dla aplikacji obsługujących OAuth 2.0 i OpenID Connect.
OAuth i OpenID Connect: przypadki użycia i praktyczne przykłady
OpenID Connect i OAuth są szeroko stosowane w różnych scenariuszach i aplikacjach. Oto kilka przykładów:
- OpenID Connect i OAuth mogą służyć do centralizacji logowania i uwierzytelniania wieloskładnikowego (MFA) dla aplikacji biznesowych. Na przykład rozwiązanie Rublon Identity Bridge pozwala aplikacjom zgodnym z OAuth 2.0 i OIDC łączyć się ze scentralizowanym serwerem autoryzacji, dzięki czemu organizacje mogą wymuszać MFA bez dodawania osobnego agenta, konektora lub niestandardowej logiki drugiego składnika do każdej aplikacji.
- OpenID Connect jest używany przez wiele stron internetowych i aplikacji mobilnych, które umożliwiają użytkownikom logowanie się za pomocą istniejących kont u dostawców takich jak Google, Facebook, Twitter itp.
- OAuth jest używany przez wiele aplikacji integrujących się z innymi usługami lub platformami, takimi jak Spotify, Instagram, Dropbox itp.
- OpenID Connect i OAuth są używane przez niektóre aplikacje łączące funkcje identyfikacji i autoryzacji, takie jak Microsoft Entra ID.
- Dostawcy tożsamości używają OpenID Connect do uwierzytelniania użytkowników i mogą egzekwować uwierzytelnianie wieloskładnikowe (MFA) oraz zasady dostępu w ramach procesu logowania. Na przykład podczas logowania do pulpitu nawigacyjnego firmy użytkownicy mogą zostać poproszeni o podanie hasła, a następnie zweryfikowanie swojej tożsamości za pomocą drugiego czynnika (np. aplikacji mobilnej, kodu SMS lub danych biometrycznych). Po pomyślnym uwierzytelnieniu OpenID Connect wysyła do aplikacji token identyfikacyjny zawierający zweryfikowane dane użytkownika.
Wzmocnienie uwierzytelniania dzięki weryfikacji wieloskładnikowej (MFA)
Podczas gdy OAuth deleguje dostęp, a OpenID Connect weryfikuje tożsamość, połączenie MFA z OIDC wzmacnia zaufanie. Na przykład we wrażliwych sytuacjach, takich jak logowanie do aplikacji w branżach o kluczowym znaczeniu, np. finansowej czy opieki zdrowotnej, OpenID Connect może zweryfikować dane uwierzytelniające użytkownika, a następnie poprosić o dodatkowy czynnik, taki jak mobilny kod weryfikacyjny, skan biometryczny lub token sprzętowy.
Taka wielopoziomowa strategia jest zgodna z wytycznymi NIST dotyczącymi uwierzytelniania o wysokim poziomie bezpieczeństwa i pomaga ograniczyć ryzyko naruszenia bezpieczeństwa danych uwierzytelniających. NIST wymaga stosowania uwierzytelniania MFA w systemach tożsamości cyfrowej działających na poziomie Authenticator Assurance Level 2 (AAL2) i Level 3 (AAL3), zwłaszcza w przypadku dostępu do wrażliwych zasobów, takich jak dane osobowe.
Podsumowanie
OpenID Connect i OAuth to dwa standardy o różnych celach i funkcjach, ale łączące pewne podobieństwa i zalety. OpenID Connect to warstwa tożsamości oparta na OAuth, która dostarcza informacji o zalogowanym użytkowniku, podczas gdy OAuth to platforma autoryzacji zapewniająca dostęp do zasobów użytkownika. Oba standardy oparte są na protokole OAuth 2.0 i wykorzystują podobny proces pozyskiwania tokenów z serwera autoryzacji. Oba standardy są również szeroko stosowane w różnych scenariuszach i aplikacjach wymagających uwierzytelniania i/lub autoryzacji.
Najczęściej zadawane pytania
Jaka jest różnica między OpenID i OAuth?
OpenID Connect (OIDC) to uwierzytelnianie, czyli potwierdzenie tożsamości użytkownika. OAuth 2.0 natomiast odpowiada za autoryzację, pozwalając aplikacjom uzyskać dostęp do zasobów użytkownika bez podawania haseł. W skrócie: OIDC mówi „kim jesteś”, OAuth mówi „co możesz zrobić”.
Czy OAuth jest częścią OpenID?
Nie. OIDC jest rozszerzeniem OAuth 2.0, czyli to OpenID Connect buduje warstwę uwierzytelniającą na bazie OAuth, ale sam OAuth funkcjonuje niezależnie jako framework autoryzacyjny.
Czym jest OpenID?
To pierwotny, zdecentralizowany protokół uwierzytelniania umożliwiający logowanie się do wielu stron za pomocą jednego konta zewnętrznego (IdP). OpenID Connect jest jego nowszą wersją, działającą jako warstwa nad OAuth.
Czy OpenID Connect jest lepszy niż OAuth2?
To zależy od potrzeb. Jeśli potrzebujesz tylko dostępu do zasobów, to wystarczy OAuth. Gdy zależy Ci na potwierdzeniu tożsamości użytkownika, OpenID Connect jest właściwym wyborem.