Jaka jest różnica między OpenID a OAuth?

Naprawdę staram się zrozumieć różnicę między OpenID a OAuth? Może to dwie zupełnie różne rzeczy?

OpenID dotyczy uwierzytelnienia (tj. Udowodnienia, kim jesteś), OAuth dotyczy uwierzytelnienia (tj. Przyznania dostępu do funkcji / danych / itp. Bez konieczności zajmowania się oryginalnym uwierzytelnieniem).

OAuth może być używany w zewnętrznych witrynach partnerów, aby umożliwić dostęp do chronionych danych bez konieczności ponownego uwierzytelniania użytkownika.

Wpis na blogu „ OpenID kontra OAuth z perspektywy użytkownika ” zawiera proste porównanie tych dwóch z perspektywy użytkownika, a „ OAuth-OpenID: Szczekasz na błędne drzewo, jeśli uważasz, że to to samo ” zawiera więcej informacji o tym.

Istnieją trzy sposoby porównania OAuth i OpenID:

1. Cele

OpenID został stworzony w celu uwierzytelnienia federacyjnego, czyli umożliwienia podmiotowi trzeciemu uwierzytelnienia Twoich użytkowników za pomocą kont, które już mają . Pojęcie federacji ma tutaj kluczowe znaczenie, ponieważ cały sens OpenID polega na tym, że można użyć dowolnego dostawcy (z wyjątkiem białych list). Nie musisz wcześniej wybierać ani negocjować umowy z dostawcami, aby umożliwić użytkownikom korzystanie z dowolnego konta, które mają.

Protokół OAuth został utworzony, aby wyeliminować potrzebę dzielenia się hasłami z aplikacjami innych firm . Zaczęło się to od rozwiązania problemu OpenID: jeśli wspierasz OpenID w swojej witrynie, nie możesz użyć poświadczeń HTTP Basic (nazwa użytkownika i hasło) w celu zapewnienia interfejsu API, ponieważ użytkownicy nie mają hasła do Twojej witryny.

Problem polega na tym, że rozdzielenie OpenID dla uwierzytelnienia i OAuth dla autoryzacji polega na tym, że oba protokoły mogą osiągnąć wiele takich samych rzeczy. Każdy z nich zapewnia inny zestaw funkcji, które są pożądane przez różne implementacje, ale zasadniczo są dość wymienne. Zasadniczo oba protokoły są metodą weryfikacji asercji (OpenID jest ograniczony do asercji „to jest to, kim jestem”, podczas gdy OAuth zapewnia „token dostępu”, który można wymieniać na dowolne obsługiwane asercje za pośrednictwem interfejsu API).

2. Funkcje

Oba protokoły umożliwiają witrynie przekierowanie użytkownika w inne miejsce i powrót z weryfikowalnym stwierdzeniem. OpenID zapewnia asertywność tożsamości, podczas gdy OAuth jest bardziej ogólny w postaci tokena dostępu, którego można następnie użyć do „zadawania pytań dostawcy OAuth” . Jednak każdy z nich obsługuje różne funkcje:

OpenID - najważniejszą funkcją OpenID jest proces wykrywania. OpenID nie wymaga twardego kodowania każdego dostawcy, z którego chcesz skorzystać z wyprzedzeniem. Za pomocą funkcji wykrywania użytkownik może wybrać dowolnego zewnętrznego dostawcę, którego chce uwierzytelnić. Ta funkcja wykrywania spowodowała również większość problemów OpenID, ponieważ sposób jej implementacji polega na użyciu identyfikatorów URI HTTP jako identyfikatorów, których większość użytkowników sieci nie otrzymuje. Inne funkcje OpenID ma obsługę rejestracji klienta ad-hoc przy użyciu wymiany DH, natychmiastowy tryb dla zoptymalizowanego doświadczenia użytkownika końcowego oraz sposób weryfikacji twierdzeń bez kolejnej podróży w obie strony do dostawcy.

OAuth - najważniejszą cechą OAuth jest token dostępu, który zapewnia długotrwałą metodę wysyłania dodatkowych żądań. W przeciwieństwie do OpenID, OAuth nie kończy się na uwierzytelnieniu, ale zapewnia token dostępu, aby uzyskać dostęp do dodatkowych zasobów udostępnianych przez tę samą usługę innej firmy. Ponieważ jednak OAuth nie obsługuje wykrywania, wymaga wcześniejszego wyboru i zakodowania na stałe dostawców, z których zdecydujesz się korzystać. Użytkownik odwiedzający Twoją witrynę nie może używać żadnego identyfikatora, tylko te wstępnie wybrane przez Ciebie. Ponadto OAuth nie ma pojęcia tożsamości, więc użycie go do logowania oznacza albo dodanie niestandardowego parametru (jak zrobiło to na Twitterze), albo wykonanie innego wywołania API w celu uzyskania aktualnie „zalogowanego” użytkownika.

3. Realizacje techniczne

Oba protokoły mają wspólną architekturę przy użyciu przekierowania w celu uzyskania autoryzacji użytkownika. W OAuth użytkownik autoryzuje dostęp do swoich chronionych zasobów, aw OpenID do ich tożsamości. Ale to wszystko, co dzielą.

Każdy protokół ma inny sposób obliczania podpisu używanego do weryfikacji autentyczności żądania lub odpowiedzi, a każdy ma inne wymagania rejestracyjne.

OpenID służy (głównie) do identyfikacji / uwierzytelniania, dzięki czemu stackoverflow.comwie, że jestem właścicielem chris.boyle.name(lub gdziekolwiek) i dlatego prawdopodobnie jestem tą samą osobą, która posiadała chris.boyle.namewczoraj i zdobyła punkty reputacyjne.

Protokół OAuth został zaprojektowany z myślą o autoryzacji do podejmowania działań w Twoim imieniu, aby stackoverflow.com(lub gdziekolwiek) mógł poprosić o pozwolenie, powiedzmy, tweetować w Twoim imieniu automatycznie, bez znajomości Twojego hasła na Twitterze.

Wiele osób wciąż to odwiedza, więc oto bardzo prosty schemat, aby to wyjaśnić

Dzięki uprzejmości Wikipedia

OAuth

Używane authorizationtylko w przypadku delegowania - co oznacza, że ​​upoważniasz podmiot zewnętrzny do dostępu do danych osobowych bez podawania hasła. Również „sesje” OAuth zwykle trwają dłużej niż sesje użytkownika. Oznacza to, że protokół OAuth umożliwia autoryzację

tj. Flickr używa OAuth, aby umożliwić usługom zewnętrznym publikowanie i edytowanie zdjęć osób w ich imieniu, bez konieczności podawania nazwy użytkownika i hasła do migotania.

OpenID

Służy do authenticatetożsamości z pojedynczym logowaniem. Wszystko, co powinien zrobić OpenID, to pozwolić dostawcy OpenID udowodnić, że tak jest. Jednak wiele witryn korzysta z uwierzytelniania tożsamości w celu zapewnienia autoryzacji (jednak można je rozdzielić)

tzn. jeden pokazuje swój paszport na lotnisku, aby uwierzytelnić (lub udowodnić), że osoba, której nazwisko widnieje na bilecie, którego używa, to oni.

Użyj OAuth, jeśli Twoi użytkownicy mogą chcieć się zalogować za pomocą Facebooka lub Twittera. Użyj OpenID, jeśli Twoi użytkownicy mają brody na szyi, którzy zarządzają własnymi dostawcami OpenID, ponieważ „nie chcą, aby ktokolwiek posiadał ich tożsamość”.

• OpenID to otwarty standard i zdecentralizowany protokół uwierzytelniania kontrolowany przez OpenID Foundation.
• OAuth to otwarty standard delegowania dostępu.
• OpenID Connect (OIDC) Łączy funkcje OpenID i OAuth, tj. Wykonuje zarówno uwierzytelnianie, jak i autoryzację.

OpenID ma postać unikalnego identyfikatora URI zarządzanego przez jakiegoś „dostawcę OpenID”, tj. Dostawcę tożsamości (idP).

OAuth może być używany w połączeniu z XACML, gdzie OAuth służy do wyrażania zgody na własność i delegowania dostępu, podczas gdy XACML służy do definiowania zasad autoryzacji.

OIDC wykorzystuje proste tokeny JSON Web (JWT), które można uzyskać za pomocą przepływów zgodnych ze specyfikacjami OAuth 2.0 . OAuth jest bezpośrednio powiązany z OIDC, ponieważ OIDC jest warstwą uwierzytelniającą zbudowaną na bazie OAuth 2.0 .

Na przykład , jeśli zdecydujesz się zalogować do Auth0 przy użyciu konta Google, użyjesz OIDC . Po pomyślnym uwierzytelnieniu w Google i autoryzacji Auth0 w celu uzyskania dostępu do informacji, Google odeśle z powrotem do Auth0 informacje o użytkowniku i przeprowadzonym uwierzytelnieniu. Informacje te są zwracane w tokenie internetowym JSON (JWT). Otrzymasz token dostępu i, na żądanie, token identyfikacyjny. Rodzaje tokenów : Źródło: OpenID Connect

Analogia :
użycie organizacja ID karta dla celów identyfikacji i zawiera żetony, przechowuje dane o pracownika wraz z odpowiedzialnego tj Campus / dostępu Brama / ODC. Karta identyfikacyjna działa jak OIDC, a Chip działa jak OAuth . więcej przykładów i wiki

OpenID i OAuth są protokołami opartymi na HTTP do uwierzytelniania i / lub autoryzacji. Oba mają na celu umożliwienie użytkownikom wykonywania działań bez podawania poświadczeń uwierzytelnienia lub ogólnych uprawnień klientom lub stronom trzecim. Chociaż są one podobne i istnieją proponowane standardy ich używania, są to osobne protokoły.

OpenID jest przeznaczony do uwierzytelniania federacyjnego. Klient akceptuje potwierdzenie tożsamości od dowolnego dostawcy (chociaż klienci mogą swobodnie dodawać dostawców do białej lub czarnej listy).

Protokół OAuth jest przeznaczony do autoryzacji delegowanej. Klient rejestruje się u dostawcy, który udostępnia tokeny autoryzacyjne, które akceptuje do wykonywania działań w imieniu użytkownika.

Protokół OAuth jest obecnie lepiej dostosowany do autoryzacji, ponieważ dalsze interakcje po uwierzytelnieniu są wbudowane w protokół, ale oba protokoły ewoluują. OpenID i jego rozszerzenia mogą być używane do autoryzacji, a OAuth może być wykorzystywany do autoryzacji, co można uznać za autoryzację braku operacji.

Uważam, że warto ponownie przyjrzeć się temu pytaniu, jak wskazano również w komentarzach, wprowadzenie OpenID Connect mogło wprowadzić więcej zamieszania.

OpenID Connect jest protokołem uwierzytelniającym, takim jak OpenID 1.0 / 2.0, ale tak naprawdę jest zbudowany na bazie OAuth 2.0, więc otrzymasz funkcje autoryzacji wraz z funkcjami uwierzytelniania. Różnica między nimi jest dość dobrze wyjaśniona szczegółowo w tym (stosunkowo nowym, ale ważnym) artykule: http://oauth.net/articles/authentication/

Wyjaśnienie różnicy między OpenID, OAuth, OpenID Connect:

OpenID to protokół uwierzytelniania, podczas gdy OAuth służy do autoryzacji. Uwierzytelnianie polega na upewnieniu się, że facet, z którym rozmawiasz, jest rzeczywiście tym, za kogo się podaje. Autoryzacja polega na podejmowaniu decyzji, co ten facet powinien mieć prawo robić.

W OpenID uwierzytelnianie jest delegowane: serwer A chce uwierzytelnić użytkownika U, ale poświadczenia U (np. Nazwa i hasło U) są wysyłane na inny serwer B, któremu ufa A (przynajmniej ufa uwierzytelniającym użytkownikom). Rzeczywiście, serwer B upewnia się, że U jest rzeczywiście U, a następnie mówi A: „ok, to jest prawdziwe U”.

W OAuth autoryzacja jest delegowana: jednostka A uzyskuje od jednostki B „prawo dostępu”, które A może pokazać serwerowi S, aby uzyskać dostęp; B może zatem dostarczyć tymczasowe, określone klucze dostępu do A, nie dając im zbyt dużej mocy. Możesz sobie wyobrazić serwer OAuth jako kluczowego mistrza w dużym hotelu; daje pracownikom klucze, które otwierają drzwi do pokojów, do których mają wejść, ale każdy klucz jest ograniczony (nie daje dostępu do wszystkich pokoi); ponadto klucze samozniszczą się po kilku godzinach.

Do pewnego stopnia autoryzacja może być nadużywana do pewnego pseudo-uwierzytelnienia, na tej podstawie, że jeśli jednostka A uzyska od B klucz dostępu przez OAuth i pokaże go serwerowi S, serwer S może wywnioskować, że B uwierzytelnił A przed udzieleniem dostępu klucz. Więc niektórzy ludzie używają OAuth tam, gdzie powinni używać OpenID. Ten schemat może, ale nie musi, być pouczający; ale myślę, że to pseudo-uwierzytelnianie jest bardziej mylące niż cokolwiek innego. OpenID Connect właśnie to robi: wykorzystuje OAuth do protokołu uwierzytelniania. W hotelowej analogii: jeśli napotkam rzekomego pracownika i ta osoba pokaże mi, że ma klucz, który otwiera mój pokój, to przypuszczam, że to prawdziwy pracownik, na tej podstawie, że główny klucz nie dałby mu klucza który otwiera mój pokój, jeśli nie był.

(źródło)

Czym różni się OpenID Connect od OpenID 2.0?

OpenID Connect wykonuje wiele takich samych zadań jak OpenID 2.0, ale robi to w sposób przyjazny interfejsowi API i może być wykorzystywany przez aplikacje natywne i mobilne. OpenID Connect definiuje opcjonalne mechanizmy niezawodnego podpisywania i szyfrowania. Podczas gdy integracja OAuth 1.0a i OpenID 2.0 wymagała rozszerzenia, w OpenID Connect możliwości OAuth 2.0 są zintegrowane z samym protokołem.

(źródło)

OpenID Connect da ci token dostępu plus token id. Token id to JWT i zawiera informacje o uwierzytelnionym użytkowniku. Jest podpisany przez dostawcę tożsamości i można go czytać i weryfikować bez uzyskiwania dostępu do dostawcy tożsamości.

Ponadto OpenID Connect standaryzuje kilka rzeczy, które oauth2 pozostawia do wyboru. na przykład zakresy, wykrywanie punktów końcowych i dynamiczna rejestracja klientów.

Ułatwia to pisanie kodu, który pozwala użytkownikowi wybierać spośród wielu dostawców tożsamości.

(źródło)

Google OAuth 2.0

Interfejsów API Google OAuth 2.0 można używać zarówno do uwierzytelniania, jak i autoryzacji. Ten dokument opisuje naszą implementację OAuth 2.0 do uwierzytelniania, która jest zgodna ze specyfikacją OpenID Connect i ma certyfikat OpenID. Dokumentacja znaleziona w Korzystanie z protokołu OAuth 2.0 w celu uzyskania dostępu do interfejsów API Google dotyczy również tej usługi. Jeśli chcesz poznać ten protokół interaktywnie, zalecamy Google Play OAuth 2.0 Playground .

(źródło)

To raczej rozszerzenie pytania niż odpowiedzi, ale może dodać perspektywy do wielkich technicznych odpowiedzi powyżej. Jestem doświadczonym programistą w wielu dziedzinach, ale nie mam nic przeciwko programowaniu w Internecie. Teraz próbuje zbudować aplikację internetową za pomocą Zend Framework.

Zdecydowanie zaimplementuje specyficzny dla aplikacji podstawowy interfejs uwierzytelniania nazwy użytkownika / hasła, ale rozpoznaje, że dla rosnącej liczby użytkowników myśl o kolejnej nazwie użytkownika i haśle odstraszającym. Chociaż nie jest to dokładnie sieć społecznościowa, wiem, że bardzo duży odsetek potencjalnych użytkowników aplikacji ma już konta na Facebooku lub Twitterze. Aplikacja tak naprawdę nie chce lub nie musi uzyskiwać dostępu do informacji o koncie użytkownika z tych witryn, chce jedynie zaoferować wygodę, nie wymagając od użytkownika konfigurowania nowych danych logowania, jeśli nie chce. Z funkcjonalnego punktu widzenia mogłoby to wydawać się potomkiem plakatu dla OpenID. Wygląda jednak na to, że ani Facebook, ani Twitter nie są dostawcami OpenID jako takimi, chociaż obsługują uwierzytelnianie OAuth w celu uzyskania dostępu do danych użytkownika.

We wszystkich artykułach, które przeczytałem o tych dwóch i różnicach między nimi, nie minęło, dopóki nie zobaczyłem powyższej obserwacji Karla Andersona, że ​​„OAuth można wykorzystać do uwierzytelnienia, co można uznać za autoryzację braku op” Widziałem wyraźne potwierdzenie, że OAuth jest wystarczająco dobry do tego, co chciałem zrobić.

W rzeczywistości, kiedy poszedłem opublikować tę „odpowiedź”, nie będąc w tym czasie członkiem, długo i ciężko szukałem na dole tej strony opcji umożliwiających identyfikację. Opcja użycia loginu OpenID lub uzyskania go, jeśli go nie posiadam, ale nic z Twittera lub Facebooka, wydaje się sugerować, że OAuth nie był odpowiedni do tego zadania. Ale potem otworzyłem kolejne okno i poszukałem ogólnego procesu rejestracji stosu - i oto jest mnóstwo opcji uwierzytelniania innych firm, w tym Facebook i Twitter. Ostatecznie zdecydowałem się użyć mojego identyfikatora Google (który jest OpenID) właśnie z tego powodu, że nie chciałem udzielać dostępu do stackoverflow do mojej listy znajomych i czegokolwiek innego, co Facebook lubi udostępniać na temat swoich użytkowników - ale przynajmniej „

Byłoby naprawdę wspaniale, gdyby ktoś mógł albo opublikować informacje lub wskaźniki do informacji o obsłudze tego rodzaju konfiguracji wielu autoryzacji trzeciej części oraz o tym, jak postępujesz z użytkownikami, którzy cofną autoryzację lub utracą dostęp do swojej witryny innej firmy. Mam również wrażenie, że moja nazwa użytkownika identyfikuje tutaj unikalne konto przelewowe, do którego mógłbym uzyskać dostęp za pomocą podstawowego uwierzytelnienia, gdybym chciał je skonfigurować, a także uzyskać dostęp do tego samego konta za pośrednictwem innych firm uwierzytelniających (np. Tak, żebym został uznany za zalogowanego w do stackoverflow, jeśli zalogowałem się do dowolnego z google, facebook lub twitter ...). Ponieważ ta strona to robi, ktoś tutaj prawdopodobnie ma dość dobry wgląd w ten temat. :-)

Przepraszam, że to było tak długie i było więcej pytaniem niż odpowiedzią - ale uwaga Karla sprawiła, że ​​wydawało się to najbardziej odpowiednie miejsce do publikowania pośród wielu wątków na temat OAuth i OpenID. Jeśli jest na to lepsze miejsce, którego nie znalazłem, z góry przepraszam, próbowałem.

OpenID potwierdza, kim jesteś.

OAuth zapewnia dostęp do funkcji zapewnianych przez stronę autoryzującą.

Obecnie pracuję nad specyfikacją OAuth 2.0 i OpenID Connect. Oto moje rozumienie: Wcześniej byli:

1. OpenID to zastrzeżona implementacja Google, umożliwiająca aplikacjom zewnętrznym, takim jak strony internetowe w gazetach, logowanie się za pomocą Google i komentowanie artykułu, a także innych przypadków użycia. Zasadniczo nie ma udostępniania hasła do strony internetowej gazety. Pozwolę sobie tu zdefiniować, to podejście w podejściu korporacyjnym nazywa się Federacja. W Federacji masz serwer, na którym uwierzytelniasz się i autoryzujesz (o nazwie IDP, dostawca tożsamości) i ogólnie przechowuje poświadczenia użytkownika. aplikacja kliencka, w której prowadzisz działalność, nazywa się SP lub usługodawca. Jeśli wrócimy do tego samego przykładu strony z gazetami, to strona z gazetami to SP, a Google to IDP. W przedsiębiorstwach problem ten został wcześniej rozwiązany za pomocą SAML. w tym czasie XML był używany do rządzenia branżą oprogramowania. Od usług sieciowych po konfigurację, wszystko przechodziło do XML, więc mamy SAML,

2. OAuth: OAuth widział, że pojawienie się stało się standardem, biorąc pod uwagę wszystkie tego rodzaju zastrzeżone rozwiązania, dlatego mieliśmy OAuth 1.o jako standard, ale tylko autoryzację. Niewiele osób zauważyło, ale to trochę zaczęło podnosić. W 2012 roku mieliśmy OAuth 2.0. CTO, architekci naprawdę zaczęli zwracać uwagę, gdy świat zmierza w kierunku przetwarzania w chmurze, a urządzenia obliczeniowe w kierunku urządzeń mobilnych i innych tego typu urządzeń. OAuth uważany był za rozwiązanie poważnego problemu, w którym klienci oprogramowania mogliby świadczyć usługę IDP jednej firmie i mieć wiele usług od różnych dostawców, takich jak Salesforce, SAP itp. Tak więc integracja tutaj wygląda tak, jakby scenariusz federacji miał jeden duży problem, używanie SAML jest kosztowne więc zbadajmy OAuth 2.o. Och, przeoczyłem jeden ważny punkt, który w tym czasie Google wyczuł, że OAuth tak naprawdę nie „

   za. OAuth 2.o nie mówi jasno, w jaki sposób nastąpi rejestracja klienta b. nie wspomina nic o interakcji między SP (Resource Server) a aplikacją kliencką (np. Analytics Server udostępniający dane to Resource Server i aplikacja wyświetlająca te dane jako Client)

Technicznie są tu już wspaniałe odpowiedzi, pomyślałem o udzieleniu krótkiej perspektywy ewolucji

OpenId używa OAuth do obsługi uwierzytelniania.

Analogicznie przypomina to, że .NET opiera się na Windows API. Możesz bezpośrednio wywołać Windows API, ale jest tak szeroki, skomplikowany, a argumenty metody tak ogromne, że możesz łatwo popełnić błędy / błędy / problemy bezpieczeństwa.

To samo z OpenId / OAuth. OpenId polega na OAuth do zarządzania uwierzytelnianiem, ale definiuje określony token (identyfikator_token), podpis cyfrowy i określone przepływy.

Chciałbym odnieść się do konkretnego aspektu tego pytania, które zostało zawarte w tym komentarzu:

OAuth: przed udzieleniem dostępu do niektórych funkcji należy przeprowadzić uwierzytelnianie, prawda? więc OAuth = co OpenId + zapewnia dostęp do niektórych funkcji? - Hassan Makarov 21 czerwca o 1:57

Tak i nie. Odpowiedź jest subtelna, więc trzymaj się mnie.

Gdy przepływ OAuth przekierowuje do usługi docelowej (dostawcy OAuth, że jest), to jest prawdopodobne, że trzeba uwierzytelnić z tej służby przed token zostaną przekazane z powrotem do aplikacji klient / usługi. Otrzymany token pozwala następnie aplikacji klienckiej wysyłać żądania w imieniu danego użytkownika.

Zwróć uwagę na ogólność tego ostatniego zdania: konkretnie napisałem „w imieniu danego użytkownika”, a nie „w imieniu ciebie ”. Często popełnianym błędem jest założenie, że „możliwość interakcji z zasobem należącym do danego użytkownika„ implikuje ”, że ty i właściciel zasobu docelowego (-ych) jesteś jednym (-ą) tym samym”.

Nie popełnij tego błędu.

Chociaż prawdą jest, że uwierzytelniasz się za pomocą dostawcy OAuth (np. Według nazwy użytkownika i hasła, a może certyfikatów klienta SSL lub w inny sposób), to, co klient otrzymuje w zamian, nie musi być traktowane jako dowód tożsamości. Przykładem może być przepływ, w którym dostęp do zasobów innego użytkownika został Ci przekazany (i przez proxy, klienta OAuth). Autoryzacja nie oznacza uwierzytelnienia.

Aby obsłużyć uwierzytelnianie, prawdopodobnie zajrzysz do OpenID Connect, który jest zasadniczo kolejną warstwą na szczycie zestawu podstawowego OAuth 2.0. Oto cytat, który uchwycił (moim zdaniem) najważniejsze punkty dotyczące OpenID Connect (od https://oauth.net/articles/authentication/ ):

OpenID Connect to otwarty standard opublikowany na początku 2014 r., Który określa interoperacyjny sposób używania OAuth 2.0 do przeprowadzania uwierzytelnienia użytkownika. Zasadniczo jest to szeroko opublikowany przepis na krówki czekoladowe, który został wypróbowany i przetestowany przez wielu różnych ekspertów. Zamiast budować inny protokół dla każdego potencjalnego dostawcy tożsamości, aplikacja może mówić jednym protokołem do tylu dostawców, ilu chce pracować. Ponieważ jest to otwarty standard, OpenID Connect może być wdrożony przez każdego bez ograniczeń i problemów związanych z własnością intelektualną.

OpenID Connect jest zbudowany bezpośrednio na OAuth 2.0 i w większości przypadków jest wdrażany wraz z infrastrukturą OAuth (lub na niej). OpenID Connect wykorzystuje także zestaw specyfikacji JSON Object Signing And Encryption (JOSE) do przenoszenia podpisanych i zaszyfrowanych informacji w różnych miejscach. W rzeczywistości wdrożenie OAuth 2.0 z funkcjami JOSE to już długa droga do zdefiniowania w pełni zgodnego systemu OpenID Connect, a różnica między nimi jest stosunkowo niewielka. Ale ta delta robi dużą różnicę, a OpenID Connect udaje się uniknąć wielu pułapek omówionych powyżej, dodając kilka kluczowych komponentów do bazy OAuth: [...]

Następnie dokument opisuje (między innymi) identyfikatory tokenów i punkt końcowy UserInfo. Pierwszy z nich zapewnia zestaw oświadczeń (kim jesteś, kiedy token został wydany itp.) I ewentualnie podpis w celu weryfikacji autentyczności tokena za pomocą opublikowanego klucza publicznego bez konieczności pytania usługi nadrzędnej), a drugi zapewnia oznacza np. zapytanie o imię / nazwisko użytkownika, adres e-mail i podobne fragmenty informacji, wszystko w ustandaryzowany sposób (w przeciwieństwie do doraźnych rozszerzeń OAuth, z których ludzie korzystali przed wystandaryzowaniem OpenID Connect).

Oba protokoły zostały utworzone z różnych powodów. Protokół OAuth został utworzony w celu autoryzowania stron trzecich do uzyskiwania dostępu do zasobów. OpenID został stworzony do zdecentralizowanego sprawdzania tożsamości. Ta strona zawiera następujące informacje:

OAuth to protokół zaprojektowany w celu weryfikacji tożsamości użytkownika końcowego i udzielania uprawnień stronom trzecim. W wyniku tej weryfikacji powstaje token. Strona trzecia może używać tego tokena do uzyskiwania dostępu do zasobów w imieniu użytkownika. Tokeny mają zakres. Zakres służy do sprawdzenia, czy zasób jest dostępny dla użytkownika, czy nie

OpenID to protokół używany do zdecentralizowanego uwierzytelniania. Uwierzytelnianie dotyczy tożsamości; Ustanowienie użytkownika jest w rzeczywistości osobą, za którą się podaje. Decentralizacja oznacza, że ​​ta usługa nie jest świadoma istnienia zasobów lub aplikacji, które wymagają ochrony. To kluczowa różnica między OAuth a OpenID.

OpenID Connect rozszerza protokół autoryzacji OAuth 2.0 do użycia jako protokół uwierzytelniania, dzięki czemu można wykonywać logowanie jednokrotne za pomocą protokołu OAuth. OpenID Connect wprowadza koncepcję tokena ID, który jest tokenem zabezpieczającym, który pozwala klientowi zweryfikować tożsamość użytkownika

OAuth 2.0 to protokół bezpieczeństwa. NIE JEST NORMĄ Uwierzytelniania ani protokołu autoryzacji.

Uwierzytelnianie z definicji odpowiada na dwa pytania.

1. Kim jest użytkownik?
2. Czy użytkownik jest obecnie obecny w systemie?

OAuth 2.0 ma następujące typy dotacji

• client_credentials: Gdy jedna aplikacja musi wchodzić w interakcje z inną aplikacją i modyfikować dane wielu użytkowników.
• kod_autoryzacji: Użytkownik deleguje serwer autoryzacji do wydania tokenu dostępu, którego klient może użyć do uzyskania dostępu do chronionego zasobu
• refresh_token: Po wygaśnięciu access_token, token odświeżania można wykorzystać, aby uzyskać nowy token access
• hasło: Użytkownik podaje swoje dane logowania klientowi, który wywołuje serwer autoryzacji i otrzymuje klucz dostępu

Wszystkie 4 mają jedną wspólną cechę: access_token, artefakt, którego można użyć do uzyskania dostępu do chronionego zasobu.

Access_token nie zapewnia odpowiedzi na 2 pytania, na które musi odpowiedzieć protokół „Uwierzytelnianie”.

Przykład wyjaśnić OAuth 2.0 (kredyty: OAuth 2 w działaniu, Manning Publications)

Porozmawiajmy o czekoladzie. Możemy zrobić wiele słodyczy z czekolady, w tym krówki, lody i ciasta. Ale żaden z nich nie może być utożsamiany z czekoladą, ponieważ wiele innych składników, takich jak śmietana i chleb, są potrzebne do wyrobu słodyczy, mimo że czekolada brzmi jak główny składnik. Podobnie OAuth 2.0 to czekolada, a pliki cookie, infrastruktura TLS, dostawcy tożsamości to inne składniki wymagane do zapewnienia funkcji „Uwierzytelniania”.

Jeśli chcesz uwierzytelnienia, możesz wybrać OpenID Connect, który oprócz „access_token” zawiera „id_token”, który odpowiada na pytania, na które musi odpowiedzieć każdy protokół uwierzytelnienia.

OAuth buduje uwierzytelnianie oprócz autoryzacji: użytkownik deleguje dostęp do swojej tożsamości do aplikacji, która następnie staje się konsumentem interfejsu API tożsamości, tym samym dowiadując się, kto autoryzował klienta w pierwszej kolejności http://oauth.net/ artykuły / uwierzytelnianie /