SSO

SSO (single sign-on) to mechanizm pojedynczego logowania: użytkownik uwierzytelnia się raz u dostawcy tożsamości, a potem korzysta z wielu aplikacji bez osobnych haseł do każdej z nich. NIST opisuje to jako efekt federacji, dzięki której użytkownik może korzystać z usług wielu stron ufających bez utrzymywania osobnych uwierzytelniaczy w każdej z nich ^[1]. Wygoda ma cenę: konto u dostawcy tożsamości staje się kluczem do wszystkich podłączonych systemów. SSO jest jednym z narzędzi zarządzania tożsamością i dostępem (IAM).

Jak działa

W SSO biorą udział trzy strony. Identity provider (IdP) uwierzytelnia użytkownika i wystawia potwierdzenie. Strona ufająca (relying party, w SAML nazywana service provider) przyjmuje to potwierdzenie i na jego podstawie wpuszcza użytkownika ^{[1] [2]}. NIST definiuje federację jako uwierzytelnienie użytkownika wobec strony ufającej bez tego, by strona ta sama sprawdzała jego uwierzytelniacze ^[1].

Potwierdzenie nazywa się asercją. Według NIST jest to weryfikowalne stwierdzenie o koncie użytkownika, przekazywane protokołem federacyjnym, takim jak SAML albo OpenID Connect ^[1]. Typowy przebieg logowania inicjowanego przez aplikację pokazuje schemat poniżej.

RYS. 1Logowanie SSO inicjowane przez aplikację

Po udanym logowaniu aplikacja zakłada własną sesję i wydaje własny token sesyjny. Od tej chwili sesja w aplikacji i sesja u dostawcy tożsamości żyją osobno.

Odmiany

W praktyce SSO w aplikacjach webowych opiera się na dwóch protokołach. Oba wymienia NIST ^[1].

SAML zdefiniowało konsorcjum OASIS jako ramy wymiany informacji o bezpieczeństwie między partnerami; wersja 2.0 stała się standardem OASIS w marcu 2005 roku ^[2]. Profil Web Browser SSO pozwala zalogować się raz u dostawcy tożsamości i przechodzić do aplikacji partnerów bez ponownego uwierzytelniania ^[2]. OASIS rozróżnia przepływ inicjowany przez aplikację i przepływ inicjowany przez dostawcę tożsamości ^[2].

OpenID Connect to według specyfikacji prosta warstwa tożsamości zbudowana nad OAuth 2.0 ^[3]. Wynikiem logowania jest ID Token, czyli token bezpieczeństwa z twierdzeniami o uwierzytelnieniu użytkownika ^[3].

W WordPressie

WordPress nie ma wbudowanego SSO. Logowanie przez zewnętrznego dostawcę tożsamości dodają wtyczki. Przykładem jest OpenID Connect Generic Client, który uwierzytelnia użytkowników przez OpenID Connect z przepływem Authorization Code ^[7]. Wtyczka może logować automatycznie albo pokazywać przycisk logowania, a przy pierwszym wejściu zakłada w bazie nowe konto WordPressa ^[7].

Z tego wynikają trzy pytania, które warto zadać przed wdrożeniem:

• jaką rolę dostaje konto założone automatycznie; zob. role i uprawnienia użytkowników i default_role;
• czy zwykły formularz logowania nadal działa i czy lokalne hasła administratorów są silne;
• co dzieje się z kontem w WordPressie, gdy użytkownik zostanie wyłączony u dostawcy tożsamości.

Ostatnia sprawa jest częstą luką. Wyłączenie konta u dostawcy tożsamości blokuje nowe logowania, ale bez dodatkowego mechanizmu wylogowania zwykle nie kończy sesji już otwartej w aplikacji. Nie usuwa też haseł aplikacji ani lokalnego hasła, jeśli takie istnieje.

Zagrożenia i skutki

SSO skupia ryzyko w jednym miejscu. Przejęcie konta u dostawcy tożsamości daje dostęp do wszystkich aplikacji, które mu ufają. Dlatego konta w IdP są celem phishingu i ataków phishing AiTM (adversary-in-the-middle).

Drugim źródłem ryzyka są błędy w obsłudze asercji. OWASP wskazuje ataki typu XML Signature Wrapping, w których atakujący przestawia elementy podpisanego dokumentu tak, by aplikacja sprawdziła podpis jednego fragmentu, a odczytała inny ^[4]. Skutkiem jest obejście uwierzytelniania i zalogowanie się jako inny użytkownik. OWASP ostrzega też, że logowanie inicjowane przez dostawcę tożsamości jest z założenia mniej bezpieczne, bo brakuje w nim ochrony przed logowaniem wymuszonym przez CSRF (Cross-Site Request Forgery) ^[4].

Jak się bronić

Po stronie dostawcy tożsamości podstawą jest silne uwierzytelnianie wieloskładnikowe (MFA), najlepiej odporne na phishing, jak FIDO2 / WebAuthn. Konta administratorów IdP wymagają osobnej ochrony, bo ich przejęcie daje kontrolę nad całą federacją.

Po stronie aplikacji liczy się rygorystyczna weryfikacja asercji:

• sprawdzać podpis kluczem pobranym wcześniej od dostawcy i zapisanym lokalnie, a nie kluczem dołączonym do dokumentu ^[4];
• walidować dokument XML schematem przed użyciem go do decyzji o bezpieczeństwie ^[4];
• sprawdzać odbiorcę: w SAML atrybut Destination i element Audience ^[4], w OpenID Connect claim aud, który musi zawierać identyfikator klienta ^[3];
• odrzucać asercje przeterminowane i użyte ponownie; NIST wymaga ochrony przed ponownym przyjęciem tej samej asercji na każdym poziomie FAL ^[1], a OpenID Connect używa w tym celu parametru nonce ^[3].

NIST przewiduje też poziom FAL3, który chroni przed przejętym dostawcą tożsamości: strona ufająca dodatkowo sama uwierzytelnia użytkownika ^[1]. Warto też aktualizować biblioteki SAML i OpenID Connect, bo błędy w nich wykraczają poza jedną aplikację.

Historia i przykłady

W sierpniu 2022 roku Sekurak opisał kampanię 0ktapus, zbadaną przez Group-IB ^[5]. Ofiary dostawały SMS-y z linkami do stron podszywających się pod logowanie Okta, czyli dostawcy tożsamości ich firm ^[5]. Atakujący zdobyli 9931 zestawów danych logowania i 5441 kodów MFA w ponad 130 organizacjach, a potem wchodzili do sieci firmowych przez VPN i narzędzia zdalnego dostępu ^[5]. Kody jednorazowe wpisane na fałszywej stronie nie powstrzymały atakujących.

W marcu 2025 roku GitLab załatał podatności CVE-2025-25291 i CVE-2025-25292 w bibliotece ruby-saml, której używa do SAML SSO ^[6]. Pozwalały one obejść uwierzytelnianie przez signature wrapping i zalogować się jako inny użytkownik, jeśli atakujący miał dostęp do ważnego dokumentu SAML ^[6]. Poprawione wersje to 17.9.2, 17.8.5 i 17.7.7 ^[6].