Zarządzanie tożsamością: SAML vs. OAuth2 vs. OpenID Connect

Wszystko zaczęło się od tego, że organizacje potrzebowały sposobu na scentralizowanie swoich systemów uwierzytelniania w celu lepszego zarządzania i bezpieczeństwa. To właśnie tam pojawiło się Single Sign On (SSO). Single sign-on (SSO) jest scentralizowaną usługą uwierzytelniania sesji i użytkowników, w której jeden zestaw poświadczeń logowania może być użyty do uzyskania dostępu do wielu aplikacji. Jej piękno tkwi w jej prostocie; usługa uwierzytelnia użytkownika na jednej platformie, umożliwiając przejrzyste logowanie do wielu wewnętrznych usług bez konieczności logowania i wylogowywania się za każdym razem.

Następnie przyszli zewnętrzni twórcy aplikacji, którzy chcieli wykorzystać wewnętrzne interfejsy API do zintegrowania ich z własnymi produktami i rozwiązaniami, to było oczywiste wyzwanie. Następnie przyszły sieci społecznościowe i jeszcze bardziej skomplikowały sprawę, obecnie mamy tysiące aplikacji, które wspierają uwierzytelnianie poprzez sieci społecznościowe takie jak Facebook, Google, Twitter, LinkedIn, itp. Problemem w tych architekturach jest wyzwanie, aby utrzymać rzeczy tak proste, jak to tylko możliwe i zwiększyć bezpieczeństwo w tym samym czasie. Rozwiązanie? Federated Identities.

Obecnie, trzy główne protokoły dla federacji tożsamości to: SAML, OAuth2 & OpenID Connect. Zanim zanurkujemy głęboko w te trzy protokoły, omówmy kilka wspólnych koncepcji, które ludzie mają tendencję do mylenia.

Jeśli chodzi o bezpieczeństwo i dostęp, uwierzytelnianie & autoryzacja to dwa terminy, które ludzie mają tendencję do przeoczenia i często są mylone, aby oznaczać to samo. Cóż, uwierzytelnianie to weryfikacja tożsamości użytkownika, podczas gdy autoryzacja to weryfikacja tego, do czego ma on dostęp.

Uwierzytelnianie to sprawdzanie poprawności danych logowania przed udzieleniem użytkownikowi dostępu do systemu. Jeśli chodzi o bezpieczeństwo, zalecane jest użycie co najmniej dwóch czynników uwierzytelniających przed przyznaniem użytkownikowi dostępu do czegokolwiek. (2FA, MFA, cyfrowe & fizyczne tokeny, itp.)

Autoryzacja następuje po procesie uwierzytelniania poprzez weryfikację uprawnień użytkownika przed przyznaniem mu dostępu do wymaganych zasobów, takich jak bazy danych, pliki, repozytoria, itp. Praktycznym przykładem może być weryfikacja loginu pracownika, aby zobaczyć, do których pięter ma dostęp.

Oba procesy autoryzacji & uwierzytelniania są kluczowe dla bezpieczeństwa i zarządzania dostępem i chociaż oba mają różne koncepcje, są krytyczne dla infrastruktury systemu i ich zrozumienie jest kluczowe dla zarządzania tożsamością i dostępem.

SAML

Security Assertion Markup Language (SAML) jest opartym na XML otwartym standardem używanym do implementacji pojedynczego logowania (SSO). SAML 2.0 został wydany w 2005 roku i jest aktualną wersją standardu.

SAML jest używany zarówno do uwierzytelniania & autoryzacji pomiędzy dwoma stronami: dostawcą usług (Office365, Salesforce, G Suite, itp.) & dostawcą tożsamości (Okta, OneLogin, Ping Identity, itp.). Dostawca usług (SP) zgadza się zaufać dostawcy tożsamości (IdP) w procesie uwierzytelniania. Odbywa się to za pośrednictwem dokumentu SAML XML wysyłanego przez IdP zawierającego uwierzytelnienie autoryzacji użytkownika &, a następnie przekierowywanego do dostawcy usług.

Rozważmy ten przykład:

• Identity Provider (IdP): Okta
• Service Provider (SP): Aplikacja Salesforce

1. Użytkownik próbuje zalogować się do aplikacji Salesforce swojej firmy z Chrome.
2. Aplikacja Salesforce odpowiada, generując żądanie SAML
3. Chrome przekierowuje użytkownika na adres URL SSO, Okta przetwarza żądanie SAML, uwierzytelnia użytkownika (może to być za pomocą nazwy użytkownika i hasła, uwierzytelniania dwuskładnikowego lub MFA, jeśli użytkownik nie znajduje się w sieci wewnętrznej firmy; jeśli użytkownik jest już uwierzytelniony w Okta, ten krok zostanie pominięty) i generuje odpowiedź SAML.
4. Okta przesyła ponownie zakodowaną odpowiedź SAML do Chrome
5. Chrome przekierowuje odpowiedź SAML do aplikacji Salesforce
6. Jeśli weryfikacja przebiegnie pomyślnie, użytkownik zostanie zalogowany do aplikacji Salesforce i uzyska dostęp do wszystkich zasobów.

OAuth2

„Jak mogę pozwolić aplikacji na dostęp do moich danych, niekoniecznie podając jej moje hasło?”

OAuth2 jest otwartym standardem używanym do autoryzacji, pozwala aplikacjom na zapewnienie aplikacji „delegowanej autoryzacji”. W przeciwieństwie do innych frameworków, które zapewniają uwierzytelnianie, OAuth tylko autoryzuje urządzenia, API, serwery z tokenami dostępu, a nie poświadczeniami i działa przez HTTPS.

Jeśli kiedykolwiek widziałeś jedno z poniższych okien dialogowych, to właśnie o tym mówimy. Jest to aplikacja pytająca, czy może uzyskać dostęp do danych w twoim imieniu. To jest właśnie OAuth.

Możesz myśleć o tym jak o hotelowych kartach kluczowych, ale dla aplikacji. Jeśli masz kartę z kluczem hotelowym, możesz uzyskać dostęp do swojego pokoju. Jak uzyskać kartę z kluczem hotelowym? Musisz wykonać proces uwierzytelniania w recepcji, aby ją otrzymać. Po uwierzytelnieniu i uzyskaniu karty kluczowej, możesz uzyskać dostęp do zasobów w całym hotelu.

OAuth definiuje cztery role:

• Właściciel zasobu: Na ogół sam użytkownik
• Klient: Aplikacja żądająca dostępu do serwera zasobów
• Serwer zasobów: Serwer przechowujący chronione dane (na przykład Facebook przechowujący profil użytkownika i jego dane osobowe)
• Serwer autoryzacji: Serwer wydający token dostępu do klienta. Ten token będzie używany przez klienta do żądania serwera zasobów.

Poniżej znajduje się diagram przepływu OAuth2.

Rozważmy ten przykład:

1. Spotify chce uzyskać dostęp do listy Twoich znajomych z Twojego konta na facebooku.
2. Jesteś przekierowywany przez Spotify do serwera autoryzacji (w tym przypadku facebook)
3. Jeśli autoryzujesz dostęp, serwer autoryzacji wysyła kod autoryzacji do klienta (Spotify) w odpowiedzi zwrotnej.
4. Kod ten jest następnie wymieniany z tokenem dostępu pomiędzy Facebookiem a Spotify.
5. Teraz Spotify jest w stanie użyć tego tokena dostępu do zapytania serwera zasobów (Facebook) i pobiera listę znajomych.

Jedną rzeczą, na którą należy zwrócić uwagę, jest to, że użytkownik nigdy nie zobaczy tokena dostępu, będzie on przechowywany w sesji. Serwer autoryzacji wysyła również inne informacje, takie jak czas życia tokena i token odświeżający.

OpenID Connect

OpenID Connect jest prostą warstwą tożsamości na szczycie protokołu OAuth 2.0, która rozszerza OAuth2 i pozwala na 'Federated Authentication'.

Przepływ procesu OpenID Connect jest podobny do przepływu autoryzacji OAuth2 z główną różnicą w postaci 'id-tokena', który pozwala na uwierzytelnienie użytkownika.

Zauważ, że Federated Authentication jest zupełnie czymś innym niż Delegated Authorization. Weźmy ponownie przykład Facebooka i Spotify

• Federated Authentication to logowanie do Spotify przy użyciu danych uwierzytelniających z Facebooka.
• Delegated Authorization to możliwość dostępu do zasobów przez zewnętrzną aplikację. W tym przypadku, Spotify próbuje uzyskać dostęp do listy znajomych na Facebooku, aby zaimportować ją do Spotify.

Aby podsumować, oto tabela podsumowująca wszystkie trzy protokoły/ramy.