Protocol · XML · SSO

SAML 2.0 is a signed hall pass.

You log in once at an identity provider. Apps never see your password. They get a sealed XML assertion that says who you are, for how long, and for which audience.

The assertion

Assertion

urn:oasis:names:tc:SAML:2.0:assertion

ds:Signature
Issuer (IdP)
idp.example
Audience (SP)
app.example

NotBefore → now → NotOnOrAfter · Conditions bound · Destination checked

SP-initiated SSO

Six hops. One login.

Hover a step. The browser is the courier; the IdP is the notary; the app is the bouncer reading the stamp.

  1. 1

    User hits the app

    Service Provider has no session. It does not ask for a password.

  2. 2

    AuthnRequest

    SP redirects the browser to the IdP with a signed request (HTTP-Redirect or POST).

  3. 3

    IdP authenticates

    Password, MFA, existing SSO cookie — whatever that IdP already trusts.

  4. 4

    Response + Assertion

    IdP POSTs a signed Response to the SP ACS URL. The assertion is the payload that matters.

  5. 5

    SP verifies

    Signature, issuer, audience, times, destination, InResponseTo. Fail any check → no session.

  6. 6

    Local session

    App maps NameID / attributes to a user and issues its own cookie. SAML’s job is done.

Three roles

Principal

The human

Subject of the assertion. Identified by NameID (email, persistent id, transient id). Attributes ride along: groups, email, displayName.

Service Provider

The app

Trusts the IdP’s certificate. Publishes an ACS URL, entityID, and usually SP metadata XML. Never stores the IdP password.

Identity Provider

The notary

Okta, Entra, Google, Keycloak, Shibboleth. Authenticates, then signs assertions for registered SPs.

Bindings you actually meet

HTTP-Redirect

AuthnRequest in the URL

Deflated + base64 in query string. Fine for small requests, not for fat assertions.

HTTP-POST

Assertion in a form post

The classic ACS handoff. Auto-submit form, then the SP consumes SAMLResponse.

Artifact

Pointer, then back-channel

Browser carries a small artifact; SP fetches the real message from the IdP server-to-server.

SP-initiated

User opens the app first. RelayState remembers where they were going. Most SaaS setups.

IdP-initiated

User clicks the app tile in the IdP portal. No AuthnRequest; SP must still verify issuer, signature, and audience.

What to check when it breaks

  • 01 Clock skew vs NotBefore / NotOnOrAfter
  • 02 ACS URL and Destination must match exactly
  • 03 Certificate rolled on the IdP, SP still has the old one
  • 04 AudienceRestriction does not include the SP entityID
  • 05 WantAssertionsSigned vs whole Response signed — verify the part you actually trust

SAML 2.0 · OASIS · 2005 · still the enterprise SSO workhorse next to OIDC