Federacyjna tożsamość: SAML, OAuth i OpenID Connect

We współczesnych przedsiębiorstwach pracownicy muszą uzyskiwać dostęp do dziesiątek aplikacji — aplikacji chmurowych, narzędzi SaaS, portali partnerów i systemów wewnętrznych — z których każda może być utrzymywana przez inną organizację. Tworzenie i zarządzanie oddzielnymi kontami dla każdej z nich jest niebezpieczne (prowadzi do nadmiernej liczby poświadczeń) i nieefektywne. Tożsamość federacyjna rozwiązuje ten problem, umożliwiając dostawcy tożsamości (IdP) — zaufanemu, nadrzędnemu źródłu informacji o tożsamości — uwierzytelnianie użytkowników i udostępnianie potwierdzonej tożsamości dostawcom usług (SP) w różnych organizacjach. Użytkownicy uwierzytelniają się raz i uzyskują dostęp do wielu systemów bez ponownego wprowadzania poświadczeń.

Jednokrotne logowanie (SSO) umożliwia użytkownikom jednokrotne uwierzytelnienie i dostęp do wielu aplikacji w ramach jednej sesji bez ponownego uwierzytelniania. Użytkownik loguje się u dostawcy tożsamości (firmowa usługa Active Directory, Okta, Azure AD), otrzymuje token sesji lub asercję i przedstawia ten token każdemu dostawcy usług, którego odwiedza. SSO zwiększa bezpieczeństwo, ponieważ zmniejsza liczbę haseł, którymi użytkownicy muszą zarządzać (ograniczając ich ponowne używanie), umożliwia centralne egzekwowanie zasad uwierzytelniania oraz pozwala natychmiast unieważnić dostęp we wszystkich zintegrowanych aplikacjach, gdy konto zostanie wyłączone na poziomie IdP.

SAML (Security Assertion Markup Language) 2.0 to oparty na XML otwarty standard wymiany danych uwierzytelniania i autoryzacji między dostawcami tożsamości a dostawcami usług. Przebieg SAML: (1) użytkownik uzyskuje dostęp do dostawcy usług (np. Salesforce), (2) SP przekierowuje go do dostawcy tożsamości (np. Okta), (3) użytkownik uwierzytelnia się u IdP, (4) IdP wystawia podpisaną asercję XML SAML Assertion zawierającą tożsamość i atrybuty użytkownika, (5) asercja wraca do SP, (6) SP weryfikuje podpis asercji za pomocą klucza publicznego IdP i przyznaje dostęp. SAML jest powszechnie używany do realizacji SSO w aplikacjach internetowych dla przedsiębiorstw.

W federacji SAML uczestniczą trzy strony. Podmiot (Principal) to użytkownik (lub system) ubiegający się o dostęp — inicjuje on proces uwierzytelniania. Dostawca tożsamości (IdP) jest nadrzędnym źródłem informacji o tożsamości, które uwierzytelnia podmiot i wystawia asercje — przykładami są Microsoft Azure AD, Okta, Ping Identity i ADFS. Dostawca usług (SP) wykorzystuje asercję i na jej podstawie przyznaje dostęp — przykładami są Salesforce, Google Workspace, AWS oraz każda aplikacja obsługująca SAML. SP i IdP ustanawiają wcześniej relację zaufania, wymieniając metadane zawierające adresy URL punktów końcowych i certyfikaty podpisujące drugiej strony.

OAuth 2.0 to struktura autoryzacji (a nie protokół uwierzytelniania), która umożliwia aplikacji zewnętrznej dostęp do zasobów w imieniu użytkownika bez ujawniania jego poświadczeń. Klasyczny przykład: „Zezwól tej aplikacji do edycji zdjęć na dostęp do usługi Google Photos”. OAuth 2.0 wprowadza cztery role: właściciela zasobu (użytkownika), klienta (aplikację zewnętrzną), serwer autoryzacji (wystawia tokeny) oraz serwer zasobów (udostępnia chroniony zasób). Użytkownik autoryzuje klienta, który otrzymuje token dostępu i przedstawia go serwerowi zasobów — bez konieczności używania rzeczywistego hasła użytkownika.

Przepływ kodu autoryzacyjnego jest najbezpieczniejszym przepływem OAuth 2.0 dla aplikacji internetowych. Przebieg: (1) klient przekierowuje użytkownika do serwera autoryzacji wraz z żądanymi zakresami; (2) użytkownik uwierzytelnia się i wyraża zgodę na serwerze autoryzacji; (3) serwer autoryzacji przekierowuje użytkownika z powrotem wraz z krótkotrwałym kodem autoryzacyjnym; (4) klient wymienia kod na token dostępu (oraz opcjonalnie token odświeżania) za pośrednictwem wywołania serwer-serwer z użyciem poświadczeń klienta; (5) klient używa tokenu dostępu do wywoływania serwera zasobów. Wymiana kodu odbywa się po stronie serwera, dzięki czemu token dostępu nie trafia do historii przeglądarki ani do dzienników.

OpenID Connect (OIDC) to warstwa uwierzytelniania zbudowana na OAuth 2.0. OAuth zapewnia wyłącznie autoryzację (tokeny dostępu potwierdzające, co klient może zrobić), natomiast OIDC dodaje uwierzytelnianie (token ID potwierdzający, kim jest użytkownik). OIDC dodaje zakres openid do przepływu OAuth i zwraca podpisany token ID JWT (JSON Web Token) wraz z tokenem dostępu. Token ID zawiera oświadczenia (imię i nazwisko, adres e-mail, sub [identyfikator podmiotu]) identyfikujące użytkownika. OIDC jest obecnie dominującym protokołem SSO w usługach dla użytkowników końcowych — przyciski „Zaloguj się przez Google/Apple/Microsoft” korzystają z OIDC.

JSON Web Tokens (JWT) to kompaktowy, bezpieczny dla adresów URL format reprezentowania oświadczeń między stronami. Token JWT składa się z trzech zakodowanych w formacie base64url części oddzielonych kropkami: nagłówka (algorytm i typ tokenu), ładunku (oświadczenia: iss, sub, aud, exp, iat oraz oświadczenia niestandardowe) i podpisu (podpis kryptograficzny weryfikujący integralność tokenu). Tokeny JWT są samowystarczalne — serwer zasobów może je zweryfikować bez komunikowania się z serwerem autoryzacji, co zwiększa wydajność i umożliwia tworzenie architektur bezstanowych. Najważniejszy wymóg bezpieczeństwa: zawsze należy weryfikować podpis JWT oraz sprawdzać oświadczenia exp (termin wygaśnięcia) i aud (odbiorcy).

Zrozumienie, kiedy stosować poszczególne standardy, ma kluczowe znaczenie na egzaminie Security+. SAML 2.0: korporacyjne SSO dla aplikacji internetowych, przepływy oparte na przeglądarce i asercje XML. Jest starszy, ale powszechnie wdrożony w przedsiębiorstwach. OAuth 2.0: autoryzacja interfejsów API — przyznawanie aplikacjom zewnętrznym ograniczonego dostępu do zasobów. Nie uwierzytelnia bezpośrednio użytkowników. OIDC: uwierzytelnianie użytkowników końcowych i we współczesnych przedsiębiorstwach (SSO), zbudowane na OAuth 2.0. Zwraca tokeny ID JWT identyfikujące użytkownika. W praktyce środowiska korporacyjne często używają SAML do SSO aplikacji, a OIDC do uwierzytelniania interfejsów API i aplikacji mobilnych. Nowoczesne środowiska cloud-native preferują OIDC zamiast SAML ze względu na format JSON/JWT i lepszą obsługę urządzeń mobilnych.

Systemy tożsamości federacyjnej wprowadzają określone wektory ataków. Ataki polegające na ponownym użyciu asercji: atakujący przechwytuje asercję SAML i używa jej ponownie, aby uzyskać dostęp. Ogranicza się to przez krótki czas życia asercji i identyfikatory asercji jednorazowego użytku. XML signature wrapping (XSW): w SAML atakujący mogą czasem zmodyfikować podpisany kod XML w celu zmiany oświadczeń przy zachowaniu ważności podpisu dla oryginalnej treści. Pomylenie algorytmów JWT: jeśli serwer akceptuje zarówno algorytmy RS256 (asymetryczny), jak i HS256 (symetryczny), atakujący może sfałszować tokeny JWT, używając klucza publicznego serwera jako sekretu HMAC dla HS256. Zawsze należy sprawdzać, czy algorytm określony w nagłówku odpowiada oczekiwanemu algorytmowi. Otwarte przekierowania: identyfikatory URI przekierowania OAuth muszą być porównywane dokładnie, aby zapobiec kradzieży tokenów wskutek przekierowania do witryn kontrolowanych przez atakującego.

Federacja tożsamości w przedsiębiorstwie często wymaga synchronizowania danych o tożsamości użytkowników między systemami. SCIM (System for Cross-domain Identity Management) to standard interfejsu API REST służący do automatyzacji tworzenia i usuwania kont użytkowników między dostawcą tożsamości a połączonymi dostawcami usług. Gdy nowy pracownik zostaje dodany do Azure AD (IdP), SCIM automatycznie tworzy jego konto w Salesforce, Slack, GitHub i innych aplikacjach zgodnych z SCIM. Po rozwiązaniu stosunku pracy SCIM jednocześnie dezaktywuje wszystkie konta, zamykając lukę czasową, w której osierocone konta mogłyby zostać wykorzystane. SCIM uzupełnia protokoły SSO (SAML/OIDC), obsługując zarządzanie cyklem życia tożsamości, którego te protokoły nie obejmują.

Sprawdź swoją znajomość zagadnień CompTIA Security+ (SY0-701) omówionych w tej lekcji.

W tej lekcji poznali Państwo: SAML 2.0 wykorzystuje asercje XML do realizacji korporacyjnego SSO opartego na przeglądarce; OAuth 2.0 to struktura autoryzacji służąca do delegowania dostępu do interfejsów API; OpenID Connect dodaje uwierzytelnianie (tokeny ID JWT) do OAuth; natomiast SCIM automatyzuje zarządzanie cyklem życia tożsamości w systemach federacyjnych. W ten sposób kończymy kurs Uwierzytelnianie i autoryzacja — następnie omówimy podstawy bezpieczeństwa sieci.