identity provider (IdP)

Identity provider (IdP) to system, który uwierzytelnia użytkowników i przekazuje aplikacjom potwierdzenie ich tożsamości w postaci tokenu albo asercji. NIST opisuje identity providera jako pomost między kontem użytkownika a usługą, do której ten użytkownik się loguje ^[1]. Usługa korzystająca z tego potwierdzenia to strona ufająca (relying party, RP) ^[1]. Takie rozdzielenie ról nazywa się federacją: aplikacja wpuszcza użytkownika bez samodzielnego sprawdzania jego hasła czy drugiego składnika ^[1].

Jak działa

W modelu federacyjnym użytkownik loguje się nie w aplikacji, lecz u identity providera. Ten wystawia asercję: weryfikowalne stwierdzenie o koncie użytkownika, zwykle z informacją o zdarzeniu uwierzytelnienia i z atrybutami tożsamości ^[1]. NIST wymienia typowe elementy asercji: identyfikator podmiotu, identyfikator wystawcy, ograniczenie odbiorcy do konkretnej aplikacji, czas wygaśnięcia i podpis cyfrowy ^[1].

Microsoft opisuje ten przebieg w czterech krokach: użytkownik otwiera aplikację, aplikacja przekierowuje go do dostawcy tożsamości, dostawca weryfikuje poświadczenia, a po potwierdzeniu tożsamości aplikacja udziela dostępu ^[5]. Aplikacje nie zarządzają wtedy oddzielnymi nazwami użytkowników i hasłami ^[5]. Na tym opiera się logowanie jednokrotne, czyli SSO.

RYS. 1Logowanie do WordPressa przez identity providera (OpenID Connect)

Odmiany

Identity providerzy komunikują się z aplikacjami za pomocą kilku protokołów. Microsoft wymienia jako protokoły federacyjne SAML 2.0 i OpenID Connect ^[5].

W SAML identity provider jest stroną wystawiającą asercje, a dostawca usługi (SP) stroną, która je wykorzystuje ^[3]. Asercje mogą zawierać stwierdzenia o uwierzytelnieniu, atrybutach podmiotu i decyzjach autoryzacyjnych ^[3]. OpenID Connect to według specyfikacji prosta warstwa tożsamości nad OAuth 2.0 ^[2]. OpenID Provider jest tam serwerem autoryzacji OAuth 2.0, który uwierzytelnia użytkownika i przekazuje aplikacji informacje o tym zdarzeniu ^[2].

NIST dzieli federację na trzy poziomy pewności. FAL1 dopuszcza zwykłe asercje okazicielskie, FAL2 wymaga ograniczenia asercji do jednej aplikacji i uprzedniego porozumienia o zaufaniu, a FAL3 wymaga asercji powiązanych z kluczem użytkownika i chroni nawet przed skompromitowanym IdP ^[1].

W WordPressie

WordPress sam jest identity providerem dla swojej witryny: przechowuje konta, hasła i sesje. Organizacje, które mają centralny katalog użytkowników, przenoszą tę rolę na zewnętrznego identity providera. Obsługę SAML albo OpenID Connect dodają zwykle wtyczki. Przykładem jest OpenID Connect Generic Client, który uwierzytelnia użytkowników przez przepływ Authorization Code, może logować automatycznie albo wyświetlać przycisk logowania i ma ponad 10 000 aktywnych instalacji ^[8]. Po pierwszym logowaniu wtyczka zakłada użytkownika w bazie WordPressa ^[8].

Taka integracja przenosi ciężar ochrony. Uwierzytelnianie wieloskładnikowe, blokady kont i polityka haseł działają po stronie IdP. WordPress nadal odpowiada za autoryzację, czyli za to, jaką rolę dostaje zalogowany użytkownik; zob. role i uprawnienia użytkowników. Automatyczne zakładanie kont warto połączyć z domyślną rolą o najmniejszych uprawnieniach. Podobną ostrożność zalecano przy błędach ruby-saml w GitLabie: jednym z doraźnych środków było wymaganie zgody administratora na tworzenie nowych kont ^[6].

Microsoft wskazuje korzyści scentralizowania logowania: użytkownik pamięta mniej danych logowania, centralne logowanie ogranicza ekspozycję poświadczeń, a administratorzy kontrolują dostęp u jednego dostawcy tożsamości ^[5]. Dla zespołu, który obsługuje wiele witryn WordPress, oznacza to, że odejście pracownika wymaga zablokowania jednego konta zamiast kilkunastu.

Zagrożenia i skutki

Identity provider staje się pojedynczym punktem zaufania. Przejęcie konta u identity providera daje dostęp do wszystkich aplikacji z nim połączonych.

• Phishing wymierzony w IdP. Kampania 0ktapus, opisana przez badaczy Group-IB, przejęła według nich prawie 10 tysięcy kont w ponad 130 organizacjach ^[7]. Ofiary dostawały SMS-y z linkami do stron podszywających się pod logowanie Okta i wpisywały tam dane logowania oraz kody drugiego składnika ^[7]. To połączenie smishingu i phishingu prowadzące do przejęcia kont.
• Błędy w weryfikacji asercji. GitLab załatał podatności CVE-2025-25291 i CVE-2025-25292 w bibliotece ruby-saml ^[6]. W pewnych warunkach atakujący z dostępem do jednego poprawnie podpisanego przez identity providera dokumentu SAML mógł zalogować się jako inny użytkownik ^[6]. Sekurak podkreślał, że włączenie drugiego składnika u identity providera nie chroniło przed tym błędem ^[6].
• Logowanie inicjowane przez IdP. OWASP zwraca uwagę, że niezamówione odpowiedzi SAML nie mają ochrony przed CSRF logowania, bo aplikacja nie może sprawdzić, czy użytkownik rzeczywiście rozpoczął logowanie ^[4].

Jak się bronić

Strona ufająca musi dokładnie sprawdzać każde potwierdzenie tożsamości. Specyfikacja OpenID Connect wymaga podpisania ID Tokenu (JWS) ^[2]. Klient ma sprawdzić, czy wystawca zgadza się z oczekiwanym OpenID Providerem, czy odbiorca zawiera jego identyfikator klienta, czy podpis jest poprawny i czy token nie wygasł ^[2].

Dla SAML OWASP zaleca między innymi:

• walidację schematu XML przed użyciem dokumentu do celów bezpieczeństwa ^[4];
• sprawdzanie, czy podpis obejmuje tę asercję, której aplikacja ufa, co utrudnia ataki typu signature wrapping ^[4];
• kontrolę znaczników czasu NotBefore i NotOnOrAfter oraz zgodności odbiorcy ^[4];
• odrzucanie algorytmów podpisu opartych na SHA-1 ^[4];
• przesyłanie asercji wyłącznie przez TLS ^[4].

Po stronie identity providera ważne są silne metody logowania, na przykład FIDO2 / WebAuthn, oraz regularna aktualizacja bibliotek obsługujących SAML i OpenID Connect. Szerszy kontekst opisuje zarządzanie tożsamością i dostępem (IAM).