Terminologia dotycząca uwierzytelniania delegowanego i federacyjnego nie jest całkowicie ustandaryzowana. Także w modelu federacyjnym aplikacja deleguje uwierzytelnianie do zewnętrznego dostawcy tożsamości (IdP). W tym artykule termin uwierzytelnianie delegowane jest jednak używany w węższym znaczeniu, w którym aplikacja przetwarza dane uwierzytelniające użytkownika i zleca ich walidację zewnętrznemu systemowi uwierzytelniania. Uwierzytelnianie federacyjne oznacza natomiast model, w którym użytkownik uwierzytelnia się u dostawcy tożsamości, a aplikacja opiera się na zaufanej asercji lub tokenie tożsamości wydanym w wyniku tego uwierzytelnienia.
Odporne na phishing FIDO MFA
Brzmi ciekawie? Wypróbuj nasze odporne na phishing uwierzytelnianie wieloskładnikowe przez 30 dni za darmo i przekonaj się, jak proste jest to rozwiązanie.
Co to jest uwierzytelnianie delegowane?
Uwierzytelnianie delegowane to model, w którym aplikacja przyjmuje dane uwierzytelniające użytkownika i deleguje ich walidację do zewnętrznego systemu uwierzytelniania, na przykład usługi katalogowej lub innej usługi uwierzytelniania. Użytkownik nadal loguje się w aplikacji, a aplikacja przetwarza jego dane uwierzytelniające, ale nie weryfikuje ich we własnym lokalnym magazynie. Zamiast tego przekazuje je do zewnętrznego systemu i wykorzystuje otrzymany wynik uwierzytelnienia.
Model ten jest często stosowany w systemach legacy i integracjach korporacyjnych opartych na scentralizowanej walidacji danych uwierzytelniających, ale wymaga odpowiedniego zabezpieczenia tych danych podczas ich przetwarzania i przesyłania przez aplikację.
Co to jest uwierzytelnianie federacyjne?
Uwierzytelnianie federacyjne opiera się na relacji zaufania między dostawcą usług lub stroną ufającą (SP/RP) a dostawcą tożsamości (IdP). Użytkownik uwierzytelnia się u dostawcy tożsamości, który wydaje asercję lub token tożsamości reprezentujący zdarzenie uwierzytelnienia i użytkownika. Dostawca usług lub strona ufająca weryfikuje ten artefakt i na jego podstawie ustanawia uwierzytelnioną sesję.
Asercja lub token mogą również zawierać dodatkowe oświadczenia dotyczące tożsamości, takie jak adres e-mail, członkostwo w grupie lub rola, ale rozbudowany zestaw atrybutów nie jest warunkiem uwierzytelniania federacyjnego. Powszechnie stosowane protokoły federacyjne obejmują protokół SAML 2.0, protokół OpenID Connect (OIDC) i protokół WS-Federation. Federacja powszechnie umożliwia Single Sign-On (SSO) pomiędzy aplikacjami i domenami tożsamości oraz ogranicza ekspozycję głównych poświadczeń użytkowników na poszczególne aplikacje.
Uwierzytelnianie federacyjne a uwierzytelnianie delegowane: na czym polega różnica?
Przy zastosowaniu opisanego wyżej, węższego znaczenia uwierzytelniania delegowanego główna różnica dotyczy sposobu, w jaki aplikacja uzyskuje potwierdzenie uwierzytelnienia użytkownika.
W przypadku uwierzytelniania delegowanego aplikacja przetwarza dane uwierzytelniające użytkownika i zleca ich walidację zewnętrznemu systemowi uwierzytelniania. W przypadku uwierzytelniania federacyjnego aplikacja zwykle nie przetwarza podstawowych danych uwierzytelniających użytkownika. Zamiast tego ufa asercji lub tokenowi tożsamości wydanemu po uwierzytelnieniu użytkownika przez dostawcę tożsamości.
Różnica dotyczy więc sposobu przetwarzania danych uwierzytelniających i przekazywania wyniku uwierzytelnienia przez granicę zaufania, a nie liczby przekazywanych oświadczeń dotyczących tożsamości ani tego, czy dostawca tożsamości komunikuje się bezpośrednio z aplikacją.
Uwierzytelnianie delegowane a uwierzytelnianie federacyjne: tabela kluczowych różnic
| Cecha | Uwierzytelnianie delegowane | Uwierzytelnianie federacyjne |
|---|---|---|
| Jak przebiega uwierzytelnianie | Aplikacja otrzymuje dane uwierzytelniające użytkownika i przekazuje je do zewnętrznego systemu uwierzytelniania w celu walidacji | Użytkownik uwierzytelnia się u dostawcy tożsamości, a aplikacja opiera się na zaufanej asercji lub tokenie tożsamości reprezentującym wynik uwierzytelnienia |
| Podstawowe dane uwierzytelniające | Są przetwarzane przez aplikację lub dostawcę usług i przekazywane do zewnętrznego systemu uwierzytelniania | Zwykle są przetwarzane wyłącznie przez dostawcę tożsamości i nie są udostępniane aplikacji ani stronie ufającej |
| Wynik uwierzytelnienia / dane o tożsamości | Często jest to wynik walidacji, a zakres dodatkowych informacji zależy od implementacji | Asercja lub token tożsamości identyfikuje uwierzytelniony podmiot i może zawierać dodatkowe oświadczenia lub atrybuty |
| Powszechnie używane mechanizmy | Protokół LDAP, protokół RADIUS lub własne interfejsy API i protokoły służące do walidacji danych uwierzytelniających | Protokół SAML 2.0, protokół OpenID Connect (OIDC), protokół WS-Federation |
| Logowanie jednokrotne | Użytkownicy zwykle uwierzytelniają się osobno w każdej aplikacji, chyba że zastosowano dodatkowy mechanizm SSO | Często umożliwia logowanie jednokrotne w wielu aplikacjach lub domenach bezpieczeństwa |
| Kwestie bezpieczeństwa | Aplikacja przetwarza podstawowe dane uwierzytelniające, co zwiększa liczbę systemów, które muszą je odpowiednio chronić | Podstawowe dane uwierzytelniające zwykle pozostają u dostawcy tożsamości, ale wymagane jest zabezpieczenie asercji, tokenów, relacji zaufania i punktów końcowych federacji |
| Typowe przypadki użycia | Systemy legacy i aplikacje wewnętrzne, urządzenia sieciowe oraz systemy wymagające walidacji centralnie zarządzanych danych uwierzytelniających, które nie obsługują protokołów federacyjnych | Aplikacje SaaS, portale partnerskie, dostęp między domenami oraz aplikacje obsługujące standardowe mechanizmy SSO |
Darmowy Trial Rublon MFA →
Zalety uwierzytelniania delegowanego w porównaniu z uwierzytelnianiem federacyjnym
- Umożliwia integrację systemów legacy i innych aplikacji z istniejącym centralnym źródłem uwierzytelniania bez konieczności obsługi protokołów federacyjnych.
- Sprawdza się w przypadku aplikacji i usług sieciowych wymagających bezpośredniego uwierzytelniania na podstawie danych uwierzytelniających.
- Pozwala scentralizować walidację danych uwierzytelniających zamiast utrzymywać osobny magazyn haseł w każdej aplikacji.
- Może wymagać mniejszych zmian w istniejącej aplikacji, która nie potrafi przetwarzać asercji federacyjnych ani tokenów tożsamości.
Zalety uwierzytelniania federacyjnego w porównaniu z uwierzytelnianiem delegowanym
- Ogranicza ekspozycję podstawowych danych uwierzytelniających użytkownika, ponieważ aplikacja lub strona ufająca zwykle ich nie przetwarza.
- Zapewnia standardowy model zaufania między aplikacją a dostawcą tożsamości przy użyciu protokołów takich jak protokół SAML 2.0 i protokół OIDC.
- Często umożliwia logowanie jednokrotne (SSO) w wielu aplikacjach i organizacjach.
- Może przekazywać oświadczenia i atrybuty tożsamości wymagane przez aplikację, pozwalając jednocześnie dostawcy tożsamości kontrolować zakres udostępnianych informacji.
- Ułatwia centralizację mechanizmów uwierzytelniania u dostawcy tożsamości i dobrze sprawdza się w scenariuszach dostępu między domenami oraz dostępu partnerskiego.
Kluczowe standardy, wytyczne i ustalenia (Delegacja & Federacja)
- NIST SP 800‑63C „Digital Identity Guidelines: Federation and Assertions (2025)” opisuje federację jako proces, w którym Dostawca Tożsamości (IdP) dostarcza atrybuty uwierzytelniania i opcjonalnie dodatkowe atrybuty subskrybenta wielu zaufanym serwerom zależnym (relying parties) poprzez assertions. NIST SP‑800‑63C
- Wzorzec Microsoftu „Federated Identity Pattern” zaleca delegować uwierzytelnianie do zaufanego zewnętrznego IdP, aby uprościć rozwój, zmniejszyć obciążenie związane z zarządzaniem danymi uwierzytelniającymi oraz poprawić doświadczenie użytkownika przez tokeny zawierające claims. Microsoft Azure – Federated Identity Pattern
- RFC 9560 (kwiecień 2024) definiuje architekturę uwierzytelniania federacyjnego dla RDAP opartego na OpenID Connect: deleguje identyfikację i uwierzytelnianie do zaufanego IdP, umożliwiając ponowne użycie istniejących identyfikatorów i zmniejszenie obciążenia użytkowników przy zarządzaniu poświadczeniami na wielu serwerach. RFC 9560 – Federated Authentication for RDAP
Wyzwania i uwagi
Choć zarówno uwierzytelnianie delegowane, jak i federacyjne mają swoje zalety, warto pamiętać o związanych z nimi kompromisach:
- Bezpieczeństwo: Przepływy delegowane wiążą się z ryzykiem wycieku danych uwierzytelniających; przepływy federacyjne wymagają silnego zabezpieczenia tokenów i ochrony oświadczeń tożsamości.
- Złożoność protokołów i infrastruktury: Konfiguracja uwierzytelniania federacyjnego (metadane, zaufanie, certyfikaty) jest bardziej złożona niż prostsze mechanizmy delegowane lub zastrzeżone.
- Doświadczenie użytkownika: Uwierzytelnianie delegowane może nie wskazywać użytkownikowi, który zewnętrzny system uwierzytelniania weryfikuje jego dane uwierzytelniające; uwierzytelnianie federacyjne może powodować dodatkowe przekierowania lub przepływy zgody.
- Niezawodność i dostępność: Zależność od zewnętrznych dostawców tożsamości lub systemów uwierzytelniania stwarza punkty krytyczne; jeśli dostawca tożsamości jest niedostępny, systemy federacyjne lub delegowane mogą ulec awarii lub degradacji.
Dlaczego dziś ma to szczególne znaczenie
Nowoczesne środowiska IAM często łączą uwierzytelnianie federacyjne z delegowaną autoryzacją, ale są to dwa różne pojęcia. Framework OAuth 2.0 służy do autoryzacji i umożliwia aplikacji klienckiej uzyskanie ograniczonego dostępu do chronionych zasobów, w tym dostępu w imieniu użytkownika. Sam framework OAuth 2.0 nie definiuje sposobu uwierzytelniania użytkownika końcowego przez aplikację.
Protokół OpenID Connect (OIDC) dodaje do frameworku OAuth 2.0 warstwę tożsamości i uwierzytelniania i może być używany do federacyjnego uwierzytelniania użytkowników. Zakresy i tokeny dostępu OAuth służą natomiast do kontrolowania delegowanego dostępu do zasobów i interfejsów API.
Starsze przepływy OAuth, w których aplikacja pobiera nazwę użytkownika i hasło, takie jak Resource Owner Password Credentials grant, nie powinny być używane we współczesnych wdrożeniach OAuth. Aktualne zalecenia bezpieczeństwa OAuth wykluczają stosowanie tego mechanizmu, ponieważ udostępnia on dane uwierzytelniające użytkownika aplikacji klienckiej i nie współpracuje z wieloma nowoczesnymi mechanizmami uwierzytelniania.
Uwierzytelnianie delegowane vs. federacyjne: które jest dla Ciebie odpowiednie?
- Wybierz uwierzytelnianie federacyjne, jeśli potrzebujesz standardowego mechanizmu SSO, relacji zaufania między domenami lub architektury, w której aplikacje nie przetwarzają podstawowych danych uwierzytelniających użytkowników. Typowymi rozwiązaniami w takich scenariuszach są protokół SAML 2.0 i protokół OIDC.
- Wybierz uwierzytelnianie delegowane w węższym znaczeniu używanym w tym artykule, jeśli system legacy, aplikacja wewnętrzna lub usługa sieciowa musi przyjmować dane uwierzytelniające użytkownika, ale może je weryfikować w zewnętrznym, scentralizowanym systemie uwierzytelniania zamiast utrzymywać własny magazyn haseł.
- Jeśli aplikacja potrzebuje ograniczonego dostępu do interfejsów API lub chronionych zasobów w imieniu użytkownika, zastosuj odpowiedni mechanizm delegowanej autoryzacji, taki jak framework OAuth 2.0. Jeśli aplikacja ma również uwierzytelniać użytkownika w tym samym ekosystemie, zastosuj protokół OpenID Connect.
Wnioski
Zarówno uwierzytelnianie delegowane, jak i uwierzytelnianie federacyjne pozwalają aplikacji korzystać z zewnętrznego systemu uwierzytelniania, ale robią to w różny sposób.
W modelu uwierzytelniania delegowanego opisanym w tym artykule aplikacja przetwarza dane uwierzytelniające użytkownika i deleguje ich walidację do innego systemu. W przypadku uwierzytelniania federacyjnego użytkownik uwierzytelnia się u dostawcy tożsamości, a aplikacja opiera się na zaufanej asercji lub tokenie tożsamości zamiast przetwarzać podstawowe dane uwierzytelniające użytkownika.
Wybór powinien więc zależeć przede wszystkim od sposobu przetwarzania danych uwierzytelniających, obsługiwanych protokołów, wymagań dotyczących SSO, modelu zaufania oraz zgodności z istniejącymi systemami, a nie od liczby oświadczeń dotyczących tożsamości wymaganych przez aplikację.