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

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

Oryginalny OpenID 2.0 vs SAML

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.

OpenID Connect vs SAML

(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_tokensam, który wystawia OAuth2.0 i nowy, id_tokenktóry jest tokenem JWT , podpisany przez dostawcę tożsamości. Aplikacja może użyć id_tokendo 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.

1. SAML2 obsługuje pojedyncze wylogowanie, ale OpenID nie
2. Dostawcy usług SAML2 są połączeni z dostawcami tożsamości SAML2, ale strony zależne OpenID nie są połączone z dostawcami OpenID. OpenID posiada protokół wykrywania, który dynamicznie wykrywa odpowiedniego dostawcę OpenID po podaniu OpenID. SAML ma protokół wykrywania oparty na protokole usługi wykrywania dostawcy tożsamości.
3. W przypadku SAML2 użytkownik jest powiązany z SAML2 IdP - Twój identyfikator SAML2 jest ważny tylko dla tego dostawcy tożsamości SAML2, który go wystawił. Ale dzięki OpenID jesteś właścicielem swojego identyfikatora i możesz go zmapować na dowolnego dostawcę OpenID.
4. SAML2 ma różne powiązania, a jedynym powiązaniem OpenID jest HTTP
5. SAML2 może być zainicjowany przez dostawcę usług (SP) lub dostawcę tożsamości (IdP). Ale OpenID zawsze inicjował SP.
6. SAML 2 jest oparty na XML, a OpenID nie.
7. Większość aplikacji opracowanych w ciągu ostatnich 3 lat obsługiwała tylko OpenID Connect.
8. 92% żądań uwierzytelnienia 8B + przekazanych przez Microsoft Azure AD w maju 2018 r. Pochodziło z aplikacji obsługujących OpenID Connect.

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:

1. Jeśli Twoim klientem są klienci indywidualni (na przykład używający identyfikatora Google), zapomnij o SAML. Użyj OpenID Connect.
2. Jeśli Twoim klientem jest bank, który chce, aby jego pracownicy korzystali z Twojej usługi i eksportowali tylko statyczną listę danych, które dostarczy do Twojej usługi, bank prawdopodobnie będzie chciał, abyś wspierał SAML. Bank może mieć implementację OpenID z ograniczeniem klienta, co będzie Twoim szczęśliwym dniem :)

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.

Scenariusz przypadku użycia:

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ść”.

Źródło