--- id: CP-193 slug: sso-saml-openid-connect lang: pl title: "SSO: SAML i OpenID Connect w prostych słowach" description: Jedno konto otwiera wiele aplikacji dzięki tokenowi. Co robią SAML i OpenID Connect oraz jak pracownik może reagować na pułapki. canonical_url: https://startbrain.io/cyberpedia/pl/articles/sso-saml-openid-connect/ markdown_url: https://startbrain.io/cyberpedia/pl/articles/sso-saml-openid-connect.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: "Brain, „SSO: SAML i OpenID Connect w prostych słowach”, Cyberpedia, 2026. https://startbrain.io/cyberpedia/pl/articles/sso-saml-openid-connect/ (CC BY 4.0)" wing: 3 theme: control_access reflex: cr-025 schema: G3 updated: "2026-11-03" translations: pl: https://startbrain.io/cyberpedia/pl/articles/sso-saml-openid-connect/ fr: https://startbrain.io/cyberpedia/fr/articles/sso-saml-openid-connect/ en: https://startbrain.io/cyberpedia/en/articles/sso-saml-openid-connect-explained/ de: https://startbrain.io/cyberpedia/de/articles/sso-saml-openid-connect/ es: https://startbrain.io/cyberpedia/es/articles/sso-saml-openid-connect/ it: https://startbrain.io/cyberpedia/it/articles/sso-saml-openid-connect/ nl: https://startbrain.io/cyberpedia/nl/articles/sso-saml-openid-connect/ pt: https://startbrain.io/cyberpedia/pt/articles/sso-saml-openid-connect/ sources: - "n": 1 title: NIST Special Publication 800-63C publisher: NIST url: https://pages.nist.gov/800-63-3/sp800-63c.html accessed: "2026-11-03" - "n": 2 title: Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK® publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1528/ accessed: "2026-11-03" - "n": 3 title: Steal Web Session Cookie, Technique T1539 - Enterprise | MITRE ATT&CK® publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1539/ accessed: "2026-11-03" - "n": 4 title: How the Microsoft identity platform uses the SAML protocol - Microsoft identity platform publisher: Microsoft url: https://learn.microsoft.com/en-us/entra/identity-platform/saml-protocol-reference accessed: "2026-11-03" - "n": 5 title: OpenID Connect (OIDC) on the Microsoft identity platform - Microsoft identity platform publisher: Microsoft url: https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc accessed: "2026-11-03" - "n": 6 title: "Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise | MITRE ATT&CK®" publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1550/001/ accessed: "2026-11-03" - "n": 7 title: SAML Security - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html accessed: "2026-11-03" - "n": 8 title: "Forge Web Credentials: SAML Tokens, Sub-technique T1606.002 - Enterprise | MITRE ATT&CK®" publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1606/002/ accessed: "2026-11-03" - "n": 9 title: "SP 800-63C-4, Digital Identity Guidelines: Federation and Assertions | CSRC" publisher: NIST url: https://csrc.nist.gov/pubs/sp/800/63/c/4/final accessed: "2026-11-03" --- # SSO: SAML i OpenID Connect w prostych słowach 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 nich [1]. 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. ## 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ła [2][3]. - 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ę. ## 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 aplikacji [1]. NIST zaznacza, że dzięki temu mechanizmowi nie trzeba mieć osobnych danych logowania do każdej usługi [1]. ### 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 SAML [1]. ### 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 aplikacji [1], 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ładnika [6], a ciasteczka sesji mogą omijać niektóre protokoły uwierzytelniania wieloskładnikowego [3]. ## Jak to działa Informacje wymieniają dwie strony: dostawca tożsamości, który uwierzytelnia osobę, oraz aplikacja, która ufa temu, co on potwierdza [4]. 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 podpisu [4]. W przypadku OIDC aplikacja pobiera też publiczny dokument konfiguracji, który podaje potrzebne adresy i klucze publiczne służące do weryfikacji podpisu tokenów [5]. OWASP opisuje dla SAML odpowiedź zawierającą asercję podpisaną cyfrowo kluczem prywatnym dostawcy tożsamości [7]. 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 tokenie [8]. 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 roku [9]; te trzy poziomy nie są więc obecną regułą [1]. ## Co Pan/Pani robi - 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 phishingowych [3]. - 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ła [6]. - 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żywana [3]. W Microsoft wylogowanie kończy sesję użytkownika [5]. - 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 aplikacji [2]. ## Pułapki ### 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 proxy [2]. ### Kradzież tokenu lub sesji Tokeny dostępu służą do wysyłania autoryzowanych żądań w imieniu użytkownika [6]. Skradzione zastępują hasło: grupa APT29 używa skradzionych tokenów, by uzyskiwać dostęp do kont bez hasła [2]. Takie dostępy przez API trudno wychwycić, nawet po stronie dostawcy, bo wyglądają jak zwykłe użycie [6]. Zmiana hasła również może nie wystarczyć, by je odciąć [6]. Tokeny odświeżania pozwalają uzyskać nowe tokeny bez pytania użytkownika [2]. ### 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ępu [2]. 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ów [2][6]. Grupa APT28 użyła aplikacji podszywających się pod „Google Defender”, „Google Email Protection” i „Google Scanner”, by atakować użytkowników Gmaila [2]. ### 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 SSO [8]. MITRE przywołuje włamanie do SolarWinds, w którym grupa APT29 tworzyła tokeny za pomocą przejętych certyfikatów podpisu SAML [8]. ## Przypadki z praktyki ### 2012: owijanie podpisu XML OWASP przypomina, że podatności implementacji SAML związane z atakami przez owijanie podpisu XML opisano w 2012 roku [7]. Wśród zaleceń OWASP jest bezpieczna walidacja podpisu cyfrowego [7]. Ta praca należy do zespołów IT, nie do pracownika. ## Źródła 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) --- Źródło oryginalne: Cyberpedia, publiczna encyklopedia cyberbezpieczeństwa i AI wydawana przez Brain. Wersja kanoniczna: https://startbrain.io/cyberpedia/pl/articles/sso-saml-openid-connect/ Możesz swobodnie wykorzystywać ten tekst na licencji CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/), pod warunkiem podania „Brain, Cyberpedia” wraz z odnośnikiem do powyższego adresu.