Cyberpediaod Brain
PLDEENESFRITNLPT

SSO: SAML i OpenID Connect w prostych słowach

Jedno konto otwiera wiele aplikacji dzięki tokenowi. Co robią SAML i OpenID Connect oraz jak pracownik może reagować na pułapki.

W 30 sekund

Gdzie to się zdarza
Przy każdym otwarciu firmowej aplikacji, która przekierowuje na wspólną stronę logowania.
Czego chce atakujący
Tokenu, ciasteczka sesji albo zgody udzielonej podstawionej aplikacji, które otwierają mu dostęp bez znajomości hasła23.
Odruch
Sprawdzić adres strony logowania, włączyć uwierzytelnianie dwuskładnikowe na głównym koncie, wylogować się na wspólnym komputerze i zgłaszać każde nieoczekiwane żądanie logowania.
Jeśli to już się stało
Bez zwłoki powiadomić dział IT, podając otwartą stronę i udzieloną zgodę.

O co chodzi

SSO (single sign-on, jednokrotne logowanie) pozwala uwierzytelnić się raz u dostawcy tożsamości, a potem uzyskać dostęp do wielu aplikacji bez zakładania i zapamiętywania osobnego hasła do każdej z nich1. Pracownik wpisuje dane logowania na firmowej stronie logowania, a aplikacje dostają dowód jego tożsamości zamiast hasła.

Do tej wymiany służą głównie dwa protokoły: SAML i OpenID Connect (OIDC). Na ekranie ich nie widać, ale ich tokeny stały się celem ataków: kradzież tokenu lub sesji oznacza kradzież dostępu.

Pytania wprost

Czym jest SSO?

Jedno konto, zarządzane przez dostawcę tożsamości, obsługuje wiele aplikacji. Dokument NIST o federacji tożsamości opisuje ten przypadek: użytkownik nie uwierzytelnia się bezpośrednio w aplikacji, tylko dostawca tożsamości tworzy asercję, często na żądanie aplikacji1. NIST zaznacza, że dzięki temu mechanizmowi nie trzeba mieć osobnych danych logowania do każdej usługi1.

Czym różni się SAML od OpenID Connect?

SAML 2.0 to protokół, który pozwala aplikacjom oferować użytkownikom SSO; wymienia asercje między dostawcą tożsamości a aplikacją4. OpenID Connect rozszerza protokół autoryzacji OAuth 2.0, czyniąc z niego protokół uwierzytelniania, a SSO odbywa się za pomocą tokenu bezpieczeństwa zwanego tokenem tożsamości (ID token)5. NIST podaje oba jako przykłady protokołów federacji, z asercją w postaci tokenu tożsamości OIDC lub asercji SAML1.

Czy SSO jest mniej bezpieczne niż osobne hasło do każdej aplikacji?

Raczej przenosi ryzyko, niż je usuwa. Pracownik nie musi już zarządzać hasłem do każdej aplikacji1, ale jedno konto otwiera wiele usług: jeśli atakujący przejmie nad nim kontrolę, narażone są wszystkie usługi, które je akceptują. Szczegóły podają pułapki opisane niżej.

Co chroni uwierzytelnianie dwuskładnikowe, a czego nie chroni?

Chroni pierwsze logowanie. Nie chroni przed tokenem lub ciasteczkiem, które już zostały skradzione: bezpośredni dostęp za pomocą tokenu niweluje działanie drugiego składnika6, a ciasteczka sesji mogą omijać niektóre protokoły uwierzytelniania wieloskładnikowego3.

1Jak to działa1 min

Informacje wymieniają dwie strony: dostawca tożsamości, który uwierzytelnia osobę, oraz aplikacja, która ufa temu, co on potwierdza4. NIST nazywa aplikację „stroną polegającą” (relying party), a komunikat dostawcy tożsamości, który informuje ją o osobie, asercją1.

W przypadku SAML Microsoft wyjaśnia, że aplikacja rejestruje u dostawcy tożsamości adres przekierowania i adres metadanych, dzięki którym można uzyskać klucz podpisu4. W przypadku OIDC aplikacja pobiera też publiczny dokument konfiguracji, który podaje potrzebne adresy i klucze publiczne służące do weryfikacji podpisu tokenów5. OWASP opisuje dla SAML odpowiedź zawierającą asercję podpisaną cyfrowo kluczem prywatnym dostawcy tożsamości7.

Token nie jest hasłem: potwierdza, że uwierzytelnienie już się odbyło. Dla SAML MITRE podaje domyślny czas życia wynoszący jedną godzinę, który można zmienić w tokenie8.

W wersji 2017/2020 swoich wytycznych, dziś zastąpionej, NIST dzieli asercje na trzy poziomy. Na pierwszym asercję podpisuje dostawca tożsamości. Na drugim jest ona dodatkowo zaszyfrowana dla aplikacji. Na trzecim użytkownik dodatkowo udowadnia, że posiada klucz powiązany z asercją1. Wersja SP 800-63C-4, z lipca 2025 roku, zastępuje wersję z 2 marca 2020 roku9; te trzy poziomy nie są więc obecną regułą1.

2Co Pan/Pani robi1 min
  • Proszę sprawdzić adres strony logowania, zanim wpisze Pan/Pani hasło. Atakujący przechwytują sesję po drodze, na przykład za pomocą narzędzi evilginx2 i Muraena, używanych w kampaniach phishingowych3.
  • Proszę włączyć uwierzytelnianie dwuskładnikowe na głównym koncie, tym, które otwiera inne aplikacje. Przejęcie dostępu do głównej skrzynki pocztowej może pozwolić dotrzeć do innych usług przez procedurę odzyskiwania zapomnianego hasła6.
  • Proszę wylogować się na wspólnym komputerze. Ciasteczka sesji często pozostają ważne przez długi czas, nawet gdy aplikacja nie jest już używana3. W Microsoft wylogowanie kończy sesję użytkownika5.
  • Proszę przeczytać okno z prośbą o zgodę, zanim Pan/Pani kliknie. Prosi ono użytkownika o przyznanie aplikacji uprawnień5.
  • Proszę zgłaszać każde żądanie logowania lub zgody, którego Pan/Pani nie wywołał(a), zwłaszcza po wiadomości zachęcającej do kliknięcia linku: w ten sposób atakujący doprowadza do udzielenia dostępu swojej aplikacji2.
3Pułapki1 min

Fałszywe portale logowania

Otwartoźródłowe frameworki evilginx2 i Muraena zbierają ciasteczka sesji przez złośliwe proxy umieszczone między ofiarą a prawdziwą witryną3. Kali365 zdobył tokeny dostępu i odświeżania OAuth, nakłaniając ofiary do zatwierdzenia żądania autoryzacji urządzenia zainicjowanego przez atakującego i przechwytując sesje dzięki infrastrukturze odwrotnego proxy2.

Kradzież tokenu lub sesji

Tokeny dostępu służą do wysyłania autoryzowanych żądań w imieniu użytkownika6. Skradzione zastępują hasło: grupa APT29 używa skradzionych tokenów, by uzyskiwać dostęp do kont bez hasła2. Takie dostępy przez API trudno wychwycić, nawet po stronie dostawcy, bo wyglądają jak zwykłe użycie6. Zmiana hasła również może nie wystarczyć, by je odciąć6. Tokeny odświeżania pozwalają uzyskać nowe tokeny bez pytania użytkownika2.

Nadużycia zgód OAuth

Atakujący rejestruje własną aplikację na serwerze autoryzacji, a potem wysyła link phishingowy, aby cel udzielił jej dostępu2. Gdy token zostanie przyznany, aplikacja może uzyskać trwały dostęp do konta, na przykład by przeszukiwać skrzynkę pocztową i wyświetlać listę kontaktów26. Grupa APT28 użyła aplikacji podszywających się pod „Google Defender”, „Google Email Protection” i „Google Scanner”, by atakować użytkowników Gmaila2.

Jedno konto jako pojedynczy punkt awarii

Kto posiada ważny certyfikat podpisu SAML, może fałszować tokeny z wybranymi uprawnieniami i czasem ważności, a tym samym uwierzytelniać się we wszystkich usługach, które używają SAML 2.0 do SSO8. MITRE przywołuje włamanie do SolarWinds, w którym grupa APT29 tworzyła tokeny za pomocą przejętych certyfikatów podpisu SAML8.

4Przypadki z praktyki1 min

2012: owijanie podpisu XML

OWASP przypomina, że podatności implementacji SAML związane z atakami przez owijanie podpisu XML opisano w 2012 roku7. Wśród zaleceń OWASP jest bezpieczna walidacja podpisu cyfrowego7. Ta praca należy do zespołów IT, nie do pracownika.

Karta

Identyfikator
CP-193
Skrzydło
3. Protokoły i obrona
Kompetencja Brain
Kontrolować dostęp (control_access)
Odruch Brain
cr-025
Schemat
G3 · Przekrój anatomiczny
Języki
de, en, es, fr, it, nl, pl, pt
Źródła
Źródła sprawdzone 3 listopada 2026: 9
ŹródłaŹródła: 9
  1. NIST, „NIST Special Publication 800-63C”. https://pages.nist.gov/800-63-3/sp800-63c.html (dostęp 3 listopada 2026)
  2. MITRE ATT&CK, „Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK®”. https://attack.mitre.org/techniques/T1528/ (dostęp 3 listopada 2026)
  3. MITRE ATT&CK, „Steal Web Session Cookie, Technique T1539 - Enterprise | MITRE ATT&CK®”. https://attack.mitre.org/techniques/T1539/ (dostęp 3 listopada 2026)
  4. Microsoft, „How the Microsoft identity platform uses the SAML protocol - Microsoft identity platform”. https://learn.microsoft.com/en-us/entra/identity-platform/saml-protocol-reference (dostęp 3 listopada 2026)
  5. Microsoft, „OpenID Connect (OIDC) on the Microsoft identity platform - Microsoft identity platform”. https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc (dostęp 3 listopada 2026)
  6. MITRE ATT&CK, „Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise | MITRE ATT&CK®”. https://attack.mitre.org/techniques/T1550/001/ (dostęp 3 listopada 2026)
  7. OWASP, „SAML Security - OWASP Cheat Sheet Series”. https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html (dostęp 3 listopada 2026)
  8. MITRE ATT&CK, „Forge Web Credentials: SAML Tokens, Sub-technique T1606.002 - Enterprise | MITRE ATT&CK®”. https://attack.mitre.org/techniques/T1606/002/ (dostęp 3 listopada 2026)
  9. NIST, „SP 800-63C-4, Digital Identity Guidelines: Federation and Assertions | CSRC”. https://csrc.nist.gov/pubs/sp/800/63/c/4/final (dostęp 3 listopada 2026)

Zacytuj ten artykuł

Brain, „SSO: SAML i OpenID Connect w prostych słowach”, Cyberpedia, 2026. https://startbrain.io/cyberpedia/pl/articles/sso-saml-openid-connect/

BibTeX 
@misc{brain_cp193_pl_2026,
  author = {Brain},
  title = {SSO: SAML i OpenID Connect w prostych słowach},
  year = {2026},
  howpublished = {Cyberpedia},
  url = {https://startbrain.io/cyberpedia/pl/articles/sso-saml-openid-connect/},
  note = {CC BY 4.0}
}
Licencja CC BY 4.0