Odpowiedzi:
Są to dwa różne protokoły uwierzytelniania i różnią się na poziomie technicznym.
Z dużej odległości różnice zaczynają się, gdy użytkownicy inicjują uwierzytelnianie. W przypadku OpenID loginem użytkownika jest zwykle adres HTTP zasobu, który jest odpowiedzialny za uwierzytelnianie. Z drugiej strony SAML opiera się na jawnym zaufaniu między Twoją witryną a dostawcą tożsamości, więc rzadko akceptuje się poświadczenia z nieznanej witryny.
Tożsamości OpenID są łatwe do poruszania się po sieci. Jako programista możesz po prostu akceptować użytkowników pochodzących od bardzo różnych dostawców OpenID. Z drugiej strony dostawca SAML zwykle wymaga wcześniejszego zakodowania, a aplikacja jest sfederowana tylko z wybranymi dostawcami tożsamości. Możliwe jest zawężenie listy akceptowanych dostawców tożsamości OpenID, ale myślę, że byłoby to sprzeczne z ogólną koncepcją OpenID.
Dzięki OpenID akceptujesz tożsamości pochodzące z dowolnych serwerów. Ktoś tak twierdzi http://someopenid.provider.com/john.smith
. Jak zamierzasz dopasować to do użytkownika w Twojej bazie danych? W jakiś sposób, na przykład przechowując te informacje na nowym koncie i rozpoznając je, gdy użytkownik ponownie odwiedzi Twoją witrynę. Pamiętaj, że nie można ufać żadnym innym informacjom o użytkowniku (w tym jego nazwisku lub adresowi e-mail)!
Z drugiej strony, jeśli istnieje wyraźne zaufanie między Twoją aplikacją a dostawcą identyfikatorów SAML, możesz uzyskać pełne informacje o użytkowniku, w tym imię i nazwisko oraz adres e-mail, a te informacje mogą być zaufane tylko ze względu na relację zaufania. Oznacza to, że masz skłonność do przekonania, że dostawca tożsamości w jakiś sposób zweryfikował wszystkie informacje i możesz mu zaufać na poziomie aplikacji. Jeśli użytkownicy pochodzą z tokenami SAML wydanymi przez nieznanego dostawcę, Twoja aplikacja po prostu odmawia uwierzytelnienia.
(sekcja dodana 07-2017, rozszerzona 08-2018)
Ta odpowiedź pochodzi z 2011 r. Iw tamtym czasie OpenID oznaczał OpenID 2.0 . Później, gdzieś w 2012 roku, został opublikowany OAuth2.0 , aw 2014 OpenID Connect (bardziej szczegółowy harmonogram tutaj ).
Dla każdego, kto to czyta w dzisiejszych czasach - OpenID Connect to nie ten sam OpenID, do którego odnosi się oryginalna odpowiedź , jest to raczej zestaw rozszerzeń do OAuth2.0.
Chociaż ta odpowiedź może rzucić trochę światła z koncepcyjnego punktu widzenia, bardzo zwięzła wersja dla kogoś, kto przychodzi z tłem OAuth2.0, jest taka, że OpenID Connect to w rzeczywistości OAuth2.0, ale dodaje standardowy sposób odpytywania informacji o użytkowniku po tokenie dostępu jest dostępny.
Nawiązując do pierwotnego pytania - jaka jest główna różnica między OpenID Connect (OAuth2.0) a SAML to sposób budowania relacji zaufania między aplikacją a dostawcą tożsamości:
SAML buduje relację zaufania na podstawie podpisu cyfrowego, tokeny SAML wydane przez dostawcę tożsamości są podpisanymi plikami XML, aplikacja sprawdza sam podpis i certyfikat, który przedstawia. Informacje o użytkowniku są zawarte między innymi w tokenie SAML.
OAuth2 tworzy relację zaufania na podstawie bezpośredniego wywołania HTTPs z aplikacji do tożsamości. Żądanie zawiera token dostępu (uzyskiwany przez aplikację w trakcie przepływu protokołu), a odpowiedź zawiera informacje o użytkowniku.
OpenID Connect dodatkowo rozszerza to, aby umożliwić uzyskanie tożsamości bez tego dodatkowego kroku obejmującego wywołanie z aplikacji do dostawcy tożsamości. Pomysł opiera się na fakcie, że dostawcy OpenID Connect w rzeczywistości wydają dwa tokeny, ten access_token
sam, który wystawia OAuth2.0 i nowy, id_token
który jest tokenem JWT , podpisany przez dostawcę tożsamości. Aplikacja może użyć id_token
do ustanowienia sesji lokalnej w oparciu o oświadczenia zawarte w tokenie JWT, ale id_token
nie można jej używać do dalszych zapytań o inne usługi, takie wywołania usług stron trzecich powinny nadal używaćaccess_token
. Możesz wtedy myśleć o OpenID Connect jako o hybrydzie między SAML2 (podpisany token) i OAuth2 (token dostępu), ponieważ OpenID Connect obejmuje tylko oba.
OpenID i SAML2 opierają się na tej samej koncepcji tożsamości federacyjnej. Poniżej przedstawiono niektóre różnice między nimi.
Pomijając szczegóły techniczne, spóźniając się na imprezę, rozumiem, że największą różnicą między SAML a innymi standardami uwierzytelniania (w tym OpenID) jest to, że
SAML wymaga, aby dostawca tożsamości (IDP) i dostawca usług (SP) znali się wcześniej, wstępnie skonfigurowane , statyczne uwierzytelnianie i autoryzacja. OpenId (+ Connect) nie ma takiego wymagania.
Jest to ważne dla dostawców tożsamości, którzy chcą mieć pełną kontrolę nad tym, kto uzyskuje dostęp do danych. Częścią standardu jest skonfigurowanie tego, co jest dostarczane do określonych dostawców usług.
Na przykład bank może nie chcieć, aby jego użytkownicy mieli dostęp do jakichkolwiek usług poza niektórymi wstępnie zdefiniowanymi (z powodu przepisów lub innych surowych zasad bezpieczeństwa).
Nie oznacza to, że OpenId IDP nie może wymusić takiego ograniczenia. Osoba wdrażająca OpenID może kontrolować dostęp, ale to nie jest celem OpenID.
Poza wstępnie zdefiniowaną, ścisłą, statyczną różnicą w kontroli dostępu, koncepcyjnie (nie technicznie), OpenID Connect i SAML są podobne.
Podsumowując, jeśli jesteś SP, powinieneś wspierać to, czego potrzebują Twoi klienci:
Zarówno SAML, jak i OpenID mogą działać jako dostawca tożsamości (w skrócie IdP), tj. Zdecentralizowany protokół uwierzytelniania (tożsamość pojedynczego logowania).
S EZPIECZEŃSTWO ssertion M arkup L anguage ( SAML ) jest zestaw profili do uwierzytelniania i autoryzacji wymiany danych między domenami bezpieczeństwa. W modelu domeny SAML dostawca tożsamości jest specjalnym typem organu uwierzytelniającego. W szczególności dostawca tożsamości SAML to jednostka systemowa, która wydaje potwierdzenia uwierzytelniania w połączeniu z profilem logowania jednokrotnego SAML. Strona ufająca, która korzysta z tych potwierdzeń uwierzytelniania, nazywana jest dostawcą usług SAML. Źródło
O pen ID C onnect ( OIDC ) to warstwa uwierzytelniania znajdująca się na szczycie OAuth 2.0, struktury autoryzacji. Standard jest kontrolowany przez OpenID Foundation. OAuth jest protokołem autoryzacji, a nie protokołem uwierzytelniania i OpenID zaprojektowanym specjalnie jako protokół uwierzytelniania. OIDC korzysta z prostych tokenów sieciowych JSON (JWT), które są łatwiejsze do wykorzystania przez JavaScript.
Użyj protokołu OAuth, jeśli Twoi użytkownicy chcą po prostu zalogować się na Facebooku lub Twitterze. Użyj OpenID, jeśli Twoi użytkownicy są karkami, którzy prowadzą własnych dostawców OpenID, ponieważ „nie chcą, aby ktokolwiek inny posiadał ich tożsamość”.