SAML 2.0 — jak działa standard federacyjnego logowania (SSO)

Czym jest SAML 2.0?

Security Assertion Markup Language w wersji 2.0 to otwarty standard wymiany danych o uwierzytelnianiu i autoryzacji pomiędzy dwiema niezależnymi stronami: dostawcą tożsamości a dostawcą usługi. Został zatwierdzony przez organizację OASIS w marcu 2005 roku i do dziś pozostaje jednym z filarów korporacyjnego logowania jednokrotnego (Single Sign-On, SSO).

Warto od razu rozwiać częste nieporozumienie. SAML nie jest modelem, biblioteką ani produktem — to standard integracyjny, zestaw formalnych specyfikacji opisujących, jak ma wyglądać komunikat uwierzytelniający, jak go podpisać i jak przesłać przez sieć. Nie jest też tym samym co OAuth czy hasło. Jego jedynym zadaniem jest pozwolić, by aplikacja docelowa zaufała stwierdzeniu „ten użytkownik został poprawnie zweryfikowany", wydanemu przez inną, zaufaną stronę, bez konieczności współdzielenia hasła.

Problem, który SAML rozwiązuje, to tak zwane zmęczenie hasłami oraz potrzeba logowania jednokrotnego w wielu domenach naraz. Klasyczne mechanizmy oparte na ciasteczkach działały wyłącznie w obrębie jednej domeny i jednego serwera. Rozwój usług chmurowych i oprogramowania B2B^?B2B: Model współpracy, w którym klientem jest inna firma, nie konsument indywidualny. W kontekście SSO oznacza wymianę tożsamości między niezależnymi organizacjami. wymusił uniwersalny sposób przekazywania tożsamości pomiędzy zupełnie niezależnymi systemami. W modelu federacyjnym usługa docelowa nigdy nie widzi hasła użytkownika — opiera się jedynie na kryptograficznym potwierdzeniu wydanym przez zaufaną stronę trzecią.

Kto za tym stoi?

SAML 2.0 nie powstał w jednym miejscu — jest fuzją trzech niezależnych nurtów. Pierwszym była organizacja OASIS, która w styczniu 2001 roku powołała komitet techniczny SSTC i doprowadziła do publikacji SAML 1.0 (listopad 2002) oraz SAML 1.1 (wrzesień 2003). Te wczesne wersje były ważne koncepcyjnie, ale brakowało im jednolitego profilu logowania webowego, a proces musiał być niemal zawsze inicjowany po stronie dostawcy tożsamości.

Drugim nurtem był Liberty Alliance, konsorcjum założone we wrześniu 2001 roku przez Sun Microsystems wraz z ponad 150 partnerami. Opracowało ono framework Identity Federation Framework (ID-FF) i wprowadziło koncepcję „kręgu zaufania" — struktury pozwalającej współdzielić poświadczenia między zrzeszonymi organizacjami. Trzecim był akademicki projekt Shibboleth, koordynowany przez sieć Internet2, który dodał prosty protokół żądań oparty na HTTP i odwrócił przepływ logowania, umożliwiając scenariusz inicjowany przez aplikację docelową.

W listopadzie 2003 roku Liberty Alliance przekazało dorobek ID-FF 1.2 do OASIS, a badacze Shibboleth oddali swoje prace temu samemu komitetowi. Wynikiem tej unifikacji był SAML 2.0, który połączył SAML 1.1, ID-FF 1.2 oraz Shibboleth 1.3 w jedną specyfikację. Poparcie gigantów, w szczególności Microsoftu, który wdrożył standard jako Active Directory Federation Services^?Active Directory Federation Services: Usługa Microsoftu (AD FS) pełniąca rolę dostawcy tożsamości SAML — uwierzytelnia użytkowników w oparciu o Active Directory i wystawia podpisane asercje aplikacjom., przypieczętowało jego dominację w segmencie korporacyjnym.

Jak to działa?

Najpowszechniejszym zastosowaniem standardu jest profil Web Browser SSO, a przeglądarka pełni w nim rolę pośrednika przenoszącego komunikaty między stronami. Przepływ inicjowany przez dostawcę usługi (SP-Initiated) jest uznawany za najbezpieczniejszy wariant operacyjny i wygląda następująco.

Przebieg logowania krok po kroku (SP-Initiated)

1. Użytkownik odwiedza chronioną aplikację, na przykład Salesforce. Aplikacja nie rozpoznaje aktywnej sesji.
2. Aplikacja generuje dokument XML typu AuthnRequest, koduje go i odsyła przeglądarce żądanie przekierowania HTTP 302.
3. Przeglądarka kieruje żądanie na adres logowania dostawcy tożsamości. Jeśli użytkownik ma już aktywną sesję globalną, krok podania poświadczeń jest pomijany — w przeciwnym razie pojawia się ekran logowania (Active Directory, uwierzytelnianie wieloskładnikowe lub biometria).
4. Po pomyślnej weryfikacji dostawca tożsamości tworzy asercję SAML, podpisuje ją swoim kluczem prywatnym i opakowuje w komunikat Response.
5. Asercja wraca do aplikacji mechanizmem HTTP POST: dostawca tożsamości generuje stronę HTML z ukrytym polem zawierającym zakodowaną odpowiedź i fragmentem JavaScriptu, który automatycznie wysyła formularz pod adres odbiorczy po stronie aplikacji (dostawcy usługi), zwany Assertion Consumer Service (ACS).
6. Aplikacja parsuje dokument, weryfikuje podpis cyfrowy znanym kluczem publicznym, sprawdza warunki (ograniczenie audytorium i czas ważności) i zakłada lokalną sesję.

Istnieje też wariant inicjowany przez dostawcę tożsamości (IdP-Initiated), w którym użytkownik startuje z firmowego pulpitu aplikacji. Jest jednak rzadszy i bardziej narażony na nadużycia parametru RelayState.

Z jakich elementów się składa?

Architektura SAML jest silnie zmodularyzowana i opiera się na czterech fundamentach.

• Asercje — podpisane dokumenty XML wydawane przez dostawcę tożsamości. Dzielą się na asercje uwierzytelniające (potwierdzają, kiedy i jak użytkownik się zalogował), asercje atrybutów (przenoszą metadane, jak rola, dział czy adres e-mail) oraz rzadziej używane asercje decyzji autoryzacyjnej.
• Protokoły — definiują format żądania i odpowiedzi. Najważniejszy to Authentication Request Protocol opisujący wymianę AuthnRequest i Response.
• Wiązania — określają, jak komunikat przejdzie przez warstwę transportową: HTTP Redirect dla krótkich żądań, HTTP POST dla obszernych asercji oraz HTTP Artifact, w którym przeglądarka przenosi jedynie krótki token, a właściwa asercja jest pobierana kanałem tylnym.
• Profile — spinają te elementy w gotowe scenariusze biznesowe, z profilem Web Browser SSO na czele.

Dwa dodatkowe elementy spajają całość.

• Metadane — pliki XML opisujące zdolności techniczne stron: unikalny Entity ID, adresy punktów końcowych oraz certyfikaty X.509, dzięki którym odbiorca może weryfikować podpisy.
• XML Signature — standard W3C chroniący integralność komunikatów. Podpis może obejmować całą odpowiedź lub samą asercję, korzysta z referencji po identyfikatorze oraz z algorytmu kanonizacji (c14n), normalizującego strukturę znaczników niezależnie od białych znaków.

Do czego może być używane?

Główną domeną SAML jest korporacyjne SSO^?SSO: Single Sign-On — jednokrotne logowanie. Jedno uwierzytelnienie daje dostęp do wielu niezależnych aplikacji bez ponownego podawania hasła. w modelach B2E^?B2E: Business-to-Employee — model, w którym odbiorcą usługi jest pracownik własnej organizacji. i B2B^?B2B: Business-to-Business — model współpracy, w którym klientem jest inna firma, nie konsument indywidualny. W kontekście SSO oznacza wymianę tożsamości między niezależnymi organizacjami.. Organizacja wdrażająca dziesiątki aplikacji chmurowych dla pracowników używa platformy tożsamości — Microsoft Entra ID, Okta, OneLogin czy Ping Identity — by jednym mechanizmem logować zespół do Salesforce, Slacka, Workday czy Boksa, bez dublowania zarządzania hasłami. Dla nowoczesnego dostawcy SaaS^?SaaS: Software as a Service — oprogramowanie dostarczane jako usługa w chmurze, z dostępem przez przeglądarkę i rozliczeniem abonamentowym. obsługa SAML jest często warunkiem zawarcia kontraktu enterprise.

Drugim wielkim obszarem są federacje akademickie i rządowe. Z racji pokrewieństwa z Shibboleth, na SAML opiera się znaczna część światowych federacji badawczych, jak amerykańska InCommon czy paneuropejski eduGAIN, a także wdrożenia sektora publicznego w ramach regulacji takich jak Login.gov czy eIDAS. Warto pamiętać o granicy: SAML nie zarządza kontami ani provisioningiem — do tworzenia i wygaszania kont używa się odrębnego standardu SCIM^?SCIM: System for Cross-domain Identity Management — standard automatyzujący zakładanie, aktualizację i usuwanie kont użytkowników między systemami (provisioning). Działa obok SAML, który odpowiada za samo logowanie., który działa obok SAML.

Czym różni się od innych rozwiązań?

OAuth 2.0

Najczęstszy błąd pojęciowy to mylenie SAML z OAuth 2.0. OAuth nie jest protokołem uwierzytelniania — to framework delegowanej autoryzacji, który pozwala aplikacji uzyskać dostęp do API w imieniu użytkownika za pomocą tokena dostępu, bez współdzielenia hasła. Najkrócej różnicę ujmują dwa pytania:

• SAML odpowiada na pytanie „kim jesteś".
• OAuth odpowiada na pytanie „do czego masz uprawnienia".

OpenID Connect

OpenID Connect (OIDC) to warstwa tożsamości nadbudowana nad OAuth 2.0. Dodaje ID Token w formacie JSON Web Token i jest znacznie lżejszy od XML-owych asercji, przez co lepiej pasuje do aplikacji mobilnych, natywnych oraz typu SPA. OIDC bywa nazywany sukcesorem SAML i faktycznie wygrywa w świecie konsumenckim i API-first.

W praktyce SAML pozostaje wyborem dla złożonych środowisk korporacyjnych, a OIDC dla nowych aplikacji webowych i mobilnych.

WS-Federation

WS-Federation to starszy standard z rodziny WS-* od Microsoftu i IBM, funkcjonalnie zbliżony do SAML, ale z czasem wyparty na rzecz tego ostatniego.

Różnice między OAuth 2.0 a SAML 2.0

Choć oba standardy bywają wymieniane jednym tchem, rozwiązują dwa różne problemy. Mylenie ich jest najczęstszym błędem pojęciowym w obszarze tożsamości — a w praktyce prowadzi do realnych luk bezpieczeństwa. SAML 2.0 powstał, by odpowiedzieć na pytanie o tożsamość. OAuth 2.0 powstał, by odpowiedzieć na pytanie o dostęp.

Uwierzytelnianie kontra autoryzacja

SAML 2.0 to protokół uwierzytelniania (authentication). Jego zadaniem jest potwierdzić aplikacji „ten użytkownik jest tym, za kogo się podaje, i właśnie się zalogował". Dostawca tożsamości weryfikuje poświadczenia i wystawia podpisaną asercję opisującą, kim jest użytkownik oraz jakie ma atrybuty.

OAuth 2.0 to natomiast framework autoryzacji (authorization) — i co kluczowe, nie jest protokołem uwierzytelniania. Jego zadaniem jest umożliwić aplikacji dostęp do zasobu w imieniu użytkownika, bez przekazywania jej hasła. Klasyczna analogia to „kluczyk dla parkingowego" (valet key): oddajesz ograniczony dostęp, nie pełną kontrolę. OAuth nie mówi nic wiarygodnego o tym, kim jest użytkownik — mówi jedynie, że aplikacja otrzymała zgodę na wykonanie określonych operacji.

To rozróżnienie ma poważną konsekwencję. Używanie samego OAuth 2.0 jako mechanizmu logowania („zaloguj przez…") jest historycznym źródłem podatności — token dostępu nie został zaprojektowany do potwierdzania tożsamości. Właśnie dlatego powstał OpenID Connect, który dokłada do OAuth 2.0 ustandaryzowaną warstwę tożsamości (ID Token). SAML pełni tę rolę natywnie, bez nadbudowy.

Format, przepływ i nośnik

SAML operuje na obszernych, podpisanych dokumentach XML przesyłanych przez przeglądarkę za pomocą przekierowań i automatycznie wysyłanych formularzy POST. To model zaprojektowany pod człowieka z przeglądarką w środowisku korporacyjnym. OAuth posługuje się lekkimi tokenami dostępu (często nieprzezroczystymi lub w formacie JWT) wymienianymi bezpośrednio między aplikacją a serwerem autoryzacji przez wywołania API. Dlatego OAuth znacznie lepiej skaluje się na aplikacje mobilne, natywne i komunikację maszyna–maszyna, gdzie ciężki XML i przepływ przez przeglądarkę byłyby przeszkodą.

Kiedy używać którego

Reguła praktyczna jest prosta. Gdy chodzi o logowanie jednokrotne pracownika do korporacyjnej aplikacji webowej, naturalnym wyborem jest SAML — to jego rdzenne zastosowanie i wymóg większości platform enterprise. Gdy chodzi o udzielenie aplikacji ograniczonego dostępu do danych lub API użytkownika bez ujawniania hasła, właściwym narzędziem jest OAuth. Gdy potrzebne jest nowoczesne uwierzytelnianie aplikacji mobilnej lub typu SPA, sięga się po OpenID Connect — czyli OAuth 2.0 z dołożoną warstwą tożsamości. W praktyce oba światy często współistnieją: SAML pilnuje, kto wchodzi do aplikacji, a OAuth pilnuje, co podłączone do niej integracje mogą zrobić z danymi użytkownika.

Najważniejsze ograniczenia i wyzwania

Sama specyfikacja SAML została wielokrotnie zweryfikowana, a podatności pojawiają się głównie na styku implementacji. Język XML jest trudny w parsowaniu i obciążony historycznym balastem, co prowadzi do błędów w bibliotekach.

XML Signature Wrapping

Najważniejszą klasą ataków jest XML Signature Wrapping (XSW). Atakujący przechwytuje legalnie podpisaną asercję, przesuwa oryginalny element niżej w drzewie XML i wstrzykuje sfałszowany fragment z podniesionymi uprawnieniami. Problem wynika z rozjazdu logiki: jeden moduł weryfikuje podpis na oryginalnym elemencie i uznaje dokument za bezpieczny, a inny odczytuje dane tożsamości z fałszywego fragmentu. Pokrewnym zagrożeniem jest XML External Entity (XXE), wykorzystujący niedbałe parsery przyjmujące złośliwe definicje DTD.

Golden SAML

Najgroźniejszy jest jednak Golden SAML, opisany przez badaczy CyberArk w 2017 roku. Atakujący, który zdobył dostęp administracyjny do dostawcy tożsamości (typowo serwera AD FS), wykrada klucz podpisujący tokeny. Od tej chwili może generować dowolne, perfekcyjnie podpisane asercje, podszywać się pod każdego użytkownika i deklarować pomyślne przejście uwierzytelniania wieloskładnikowego, całkowicie je neutralizując. Ten wektor odegrał kluczową rolę w naruszeniu łańcucha dostaw SolarWinds^?SolarWinds: Amerykańska firma IT, której oprogramowanie Orion stało się w 2020 roku wektorem głośnego ataku na łańcuch dostaw, dotykającego agencji rządowych USA i tysięcy organizacji. wykrytym pod koniec 2020 roku. Wariant Silver SAML^?Silver SAML: Wariant ataku Golden SAML opisany przez Semperis w 2024 roku, przenoszący mechanizm fałszowania asercji na chmurowe Microsoft Entra ID., opisany przez Semperis^?Semperis: Firma zajmująca się bezpieczeństwem tożsamości (m.in. ochroną Active Directory i Entra ID), która opisała atak Silver SAML. w 2024 roku, przenosi podobny mechanizm na chmurowe środowiska Microsoft Entra ID, wykorzystując import zewnętrznie generowanych certyfikatów podpisujących.

SAML jako brama do narzędzi AI enterprise

Jedną z mniej oczywistych ról SAML w 2024 roku jest to, że stał się on infrastrukturą warunkującą tempo adopcji narzędzi AI w organizacjach. Każde poważne rozwiązanie AI klasy enterprise stawia poprawną integrację SSO jako wymóg kontraktowy — i w zdecydowanej większości przypadków oznacza to właśnie SAML.

ChatGPT Enterprise, GitHub Copilot, Microsoft 365 Copilot, Salesforce Einstein, Google Workspace AI, Workday AI, ServiceNow — każde z tych wdrożeń wymaga od klienta korporacyjnego poprawnie skonfigurowanego dostawcy tożsamości zgodnego z SAML 2.0. Powód jest pragmatyczny: bez centralnej kontroli dostępu organizacja nie może zagwarantować, że do narzędzia AI mają dostęp wyłącznie uprawnione osoby ani że odejście pracownika automatycznie cofa mu dostęp.

Oznacza to, że organizacje, które nie wdrożyły SAML, napotykają na hamulec adopcji AI — zanim zdążą ocenić sam model, muszą naprawić infrastrukturę tożsamości. Odwrotnie: firmy z dojrzałą warstwą SAML (Okta, Microsoft Entra ID jako IdP, ADFS) mogą podłączyć nowe narzędzie AI w kwestii godzin, konfigurując jedną integrację dostawcy usług. SAML staje się de facto przepustką umożliwiającą skalowanie narzędzi AI w środowisku korporacyjnym.

Pojawia się też nowy wektor ryzyka: im więcej aplikacji AI jest podłączonych do jednego IdP przez SAML, tym bardziej łakomy cel stanowi dostawca tożsamości. Atak Golden SAML na IdP obsługujący jednocześnie dostęp do ChatGPT Enterprise, GitHub Copilot i platformy HR daje atakującemu wgląd w dane wrażliwe na niespotykanie szerokim froncie.

Agenci AI a granica SAML

SAML zakłada jedno fundamentalne założenie: po drugiej stronie komunikatu stoi człowiek z przeglądarką. Agenci AI tego założenia nie spełniają — i jest to granica strukturalna, nie kwestia brakującej funkcji.

Profil Web Browser SSO^?Web Browser SSO: Najpopularniejszy profil SAML — opisuje przepływ logowania jednokrotnego, w którym komunikaty wędrują między stronami przez przeglądarkę użytkownika. wymaga user-agenta^?user-agent: Program po stronie użytkownika komunikujący się z serwerami — w praktyce przeglądarka internetowa., który wyśle żądanie HTTP, przetworzy przekierowanie HTTP 302, wyrenderuje formularz logowania i wykona automatyczne wysłanie formularza POST pod adres ACS^?ACS: Assertion Consumer Service — punkt końcowy po stronie aplikacji (dostawcy usługi), który odbiera i przetwarza odpowiedź SAML z asercją.. Agent działający programatycznie — orkiestrator LLM, pipeline RAG, skrypt automatyzacji RPA — nie dysponuje tymi możliwościami. Może co prawda symulować przeglądarkę headless, ale to obejście podatne na błędy i nieakceptowalne w środowisku produkcyjnym z rygorem bezpieczeństwa.

Jak uwierzytelnia się tożsamość maszyn

Dla komunikacji maszynowej (M2M) branża ustaliła inne narzędzia. OAuth 2.0 Client Credentials Flow wydaje token aplikacji (nie człowiekowi) bez żadnej interakcji użytkownika. OIDC Workload Identity — w implementacjach takich jak Microsoft Entra Workload Identities^?Microsoft Entra Workload Identities: Mechanizm Microsoft Entra przypisujący tożsamość aplikacjom i usługom (workloadom), a nie ludziom — do uwierzytelniania maszyna–maszyna. czy Google Workload Identity Federation^?Google Workload Identity Federation: Usługa Google Cloud pozwalająca workloadom spoza GCP uwierzytelniać się bez długoterminowych kluczy serwisowych, na bazie zewnętrznego dostawcy tożsamości. — przypisuje kryptograficzną tożsamość do workloadu uruchamiającego się w chmurze. SPIFFE/SPIRE^?SPIFFE/SPIRE: Otwarty standard (SPIFFE) i jego implementacja (SPIRE) nadające usługom kryptograficzną tożsamość w środowiskach cloud-native, niezależną od statycznych sekretów. dostarcza certyfikaty SVID^?SVID: SPIFFE Verifiable Identity Document — dokument tożsamości (zwykle certyfikat X.509 lub JWT) wystawiany usłudze w modelu SPIFFE. dla serwisów w środowiskach cloud-native, uniezależniając tożsamość od tajnych kluczy statycznych.

SAML nie ma odpowiednika żadnego z tych mechanizmów dla klientów programatycznych. Asercja SAML nie jest powiązana dowodem posiadania klucza (Proof of Possession), co oznacza, że przechwycony token SAML można wielokrotnie odtworzyć — w przeciwieństwie do tokenów DPoP^?DPoP: Demonstrating Proof of Possession — mechanizm OAuth 2.0 wiążący token kryptograficznie z kluczem klienta, przez co skradziony token nie da się odtworzyć. w OAuth 2.0, które są kryptograficznie związane z konkretnym kluczem klienta.

Delegacja uprawnień i problem agentic AI

Najtrudniejszy scenariusz to agent działający w imieniu użytkownika: wysyła e-maile w jego imieniu, odczytuje dokumenty z SharePointa, wypełnia formularze w systemach ERP^?ERP: Enterprise Resource Planning — zintegrowany system do zarządzania kluczowymi procesami firmy (finanse, kadry, magazyn, produkcja).. Użytkownik uwierzytelnił się przez SAML, ale agent potrzebuje tokena z ograniczonym zakresem uprawnień — i tu architektura SAML nie ma gotowej odpowiedzi.

W praktyce rozwiązuje się to przez hybrydę: użytkownik loguje się przez SAML SSO, a platforma (np. Microsoft Entra) wydaje w tle token OAuth z precyzyjnie zdefiniowanymi zakresami (scopes), który przekazywany jest agentowi. Agent nigdy nie widzi poświadczeń SAML — operuje wyłącznie na tokenie OAuth z ograniczonym czasem życia. To architektura odpowiedzialna, ale wymaga świadomego zaprojektowania, a większość legacy systemów SAML jej nie implementuje automatycznie.

Rysuje się wyraźna linia podziału: SAML kontroluje dostęp ludzkich użytkowników do aplikacji AI, natomiast OAuth i OIDC stają się językiem tożsamości dla agentów działających w ich imieniu. Oba światy muszą być spójne — luka między nimi to powierzchnia ataku.

Dlaczego to jest istotne?

Łatwo dziś uznać SAML za relikt, skoro nowe projekty domyślnie sięgają po OIDC i tokeny JWT. Byłby to jednak błąd perspektywy. Według szacunków branżowych około dwóch trzecich korporacyjnych środowisk wciąż w jakimś zakresie opiera politykę logowania na SAML, a w dużych organizacjach z systemami dziedzictwa odsetek ten jest jeszcze wyższy. Te liczby to wartości orientacyjne z analiz rynkowych, nie twardy pomiar, ale skala zależności jest realna i nie zniknie w ciągu kilku lat.

Istotniejsze jest to, czego SAML uczy o samej naturze federacji tożsamości. Architektura, w której zaufanie sprowadza się do jednego klucza podpisującego, pokazuje, że dostawca tożsamości staje się pojedynczym punktem katastrofy — i że atak na niego, jak Golden SAML, bywa znacznie groźniejszy niż wykradzenie pojedynczych haseł. To lekcja, która przenosi się jeden do jednego na świat OIDC i każdej przyszłej federacji. W praktyce SAML i OIDC coraz częściej współistnieją, a warstwy pośredniczące tłumaczą asercje XML na tokeny JWT. Dla inżyniera oznacza to, że znajomość SAML nie jest archeologią, lecz warunkiem bezpiecznego utrzymania środowisk, które realnie obsługują dziś logowanie milionów pracowników.

SAML 2.0 to dojrzały, dobrze zrozumiany standard, który mimo dwóch dekad na karku pozostaje rdzeniem korporacyjnego logowania. Jego siła leży w formalnym rygorze i sprawdzalności podpisów, a jego słabości — niemal zawsze w implementacji, nie w samej specyfikacji.

Źródła

• OASIS — Security Assertion Markup Language (SAML) v2.0 Technical Overview — link
• Okta — What is SAML and how does it work? — link
• Auth0 — SAML Authentication — link
• CyberArk — Golden SAML: Newly Discovered Attack Technique Forges Authentication to Cloud Apps — link
• Semperis — Silver SAML: Vulnerability in Microsoft Entra ID — link
• Wikipedia — SAML 2.0 — link
• IETF — RFC 6749: The OAuth 2.0 Authorization Framework — link
• OpenID Foundation — OpenID Connect Core 1.0 — link
• IETF — RFC 7644: System for Cross-domain Identity Management (SCIM) Protocol — link
• IETF — RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) — link
• SPIFFE — SPIFFE Overview — link
• Microsoft Learn — Workload identities in Microsoft Entra — link
• CISA — Emergency Directive 21-01: Mitigate SolarWinds Orion Code Compromise — link