diagrams
Authentication

SAML Authentication Flow

Security Assertion Markup Language (SAML) 2.0 is an XML-based standard for federated identity and single sign-on, widely used in enterprise environments to allow employees to access multiple applications using their corporate credentials.

diagram.mmd — sequence
Edit in Graphlet →
SAML Authentication Flow sequence diagram
About Source

Security Assertion Markup Language (SAML) 2.0 is an XML-based standard for federated identity and single sign-on, widely used in enterprise environments to allow employees to access multiple applications using their corporate credentials.

SAML defines three roles: the User (the human logging in), the Service Provider (SP — the application being accessed), and the Identity Provider (IdP — the corporate identity system, such as Okta, Azure AD, or ADFS). The trust relationship between SP and IdP is established in advance by exchanging metadata: the SP registers its entityID, ACS URL (Assertion Consumer Service), and accepted signing certificates with the IdP; the IdP registers its entityID, SSO URL, and public key with the SP.

The SP-initiated flow begins when a user attempts to access a protected resource. The SP detects that the user is not authenticated and constructs a SAML AuthnRequest — an XML document identifying the SP and the requested resource. This request is typically encoded, compressed, and embedded in a redirect URL that sends the user's browser to the IdP's SSO endpoint.

The IdP presents a login page (or transparently authenticates the user if they have an active SSO session). After successful authentication, the IdP constructs a SAML Assertion — an XML document containing the user's identity attributes (email, name, roles), the authentication event details, and conditions (valid time window, intended audience). The IdP signs the assertion with its private key and sends it back to the SP's ACS URL via an HTTP POST from the browser (the assertion travels through the user's browser, not directly between servers).

The SP validates the assertion signature using the IdP's public key, checks the audience and time conditions, extracts the user attributes, and creates an application session. This pattern is the basis for enterprise SSO Architecture. Modern greenfield projects tend to favor OpenID Connect Flow over SAML, but SAML remains dominant in legacy enterprise environments.

Free online editor
Edit this diagram in Graphlet
Fork, modify, and export to SVG or PNG. No sign-up required.
Open in Graphlet →

Frequently asked questions

SAML (Security Assertion Markup Language) 2.0 is an XML-based standard for federated identity and single sign-on. It enables users to authenticate once with a corporate Identity Provider (such as Okta or Azure AD) and access multiple Service Provider applications without re-entering credentials. SAML is the dominant SSO standard in enterprise environments.
In the SP-initiated flow, the user accesses a protected resource at the Service Provider. The SP constructs a SAML AuthnRequest, encodes and compresses it, and redirects the user's browser to the IdP's SSO endpoint. The IdP authenticates the user, builds a signed XML SAML Assertion containing identity attributes, and POSTs it back to the SP's Assertion Consumer Service (ACS) URL via the user's browser. The SP validates the signature, checks the time and audience conditions, and establishes a session.
SAML is an authentication protocol that uses XML assertions to prove identity — it was designed for enterprise browser-based SSO. OAuth2 is an authorization framework that delegates access rights using tokens — it was designed for API access on behalf of a user. OpenID Connect is an identity layer on top of OAuth2 that adds authentication, using JSON and JWTs instead of XML. SAML and OIDC solve the same authentication problem; OAuth2 solves a related but distinct authorization problem.
Choose SAML when integrating with enterprise customers whose IT departments require it — particularly in regulated industries (healthcare, finance, government) where SAML-based IdPs are already deployed. Choose OIDC for new applications, mobile apps, and any integration where JSON/REST is more natural than XML. Most modern SaaS products support both to accommodate all enterprise customers.
Frequent mistakes include: not validating the assertion signature (trusting unsigned assertions); ignoring the `NotBefore` and `NotOnOrAfter` time conditions, which allows replay attacks; misconfiguring the `Audience` restriction so assertions intended for one SP are accepted by another; and not verifying the ACS URL in the AuthnRequest against the pre-registered URL, enabling open redirect attacks.
mermaid
sequenceDiagram participant User participant SP as Service Provider participant Browser as User Browser participant IdP as Identity Provider User->>SP: Access protected resource SP-->>SP: Detect unauthenticated user SP-->>SP: Build SAML AuthnRequest XML SP->>Browser: Redirect to IdP SSO URL with AuthnRequest Browser->>IdP: GET SSO URL with encoded AuthnRequest IdP-->>IdP: Parse and validate AuthnRequest IdP->>User: Show corporate login page User->>IdP: Submit username and password IdP-->>IdP: Validate credentials IdP-->>IdP: Build SAML Assertion with user attributes IdP-->>IdP: Sign assertion with IdP private key IdP->>Browser: HTML auto-submit form with SAMLResponse Browser->>SP: POST /acs with SAMLResponse (base64 XML) SP-->>SP: Decode and parse SAMLResponse SP-->>SP: Validate signature with IdP public key SP-->>SP: Check audience, conditions, and expiry SP-->>SP: Extract user attributes (email, roles) SP-->>SP: Create application session SP->>Browser: Redirect to original resource Browser-->>User: Access granted
Copied to clipboard