SAML: Signing in across organisations

In short: An XML-based standard for single sign-on in which an identity provider confirms to an application who has signed in.

In more detail: SAML (Security Assertion Markup Language) 2.0 is used mainly in companies and universities. The user signs in at the identity provider (IdP); the application (the service provider, SP) trusts its signed statement (“assertion”) and does not have to manage its own password.

In Depth

Flow (SP-initiated)

1. You open the application (SP).
2. The SP redirects your browser to the IdP with an AuthnRequest.
3. You sign in at the IdP (if not already signed in), possibly with two factors.
4. The IdP sends a signed assertion back to the SP via your browser (HTTP POST).
5. The SP checks signature, validity and audience and creates a session.

What an assertion contains

An assertion contains the identity (NameID), the validity time window, the intended recipient (Audience) and attributes such as email, name or groups. Trust arises from the exchange of metadata (addresses and certificates) between IdP and SP.

SAML and OpenID Connect

Both pursue the same goal. SAML is older, XML-based and common in the enterprise world, in university federations and in public authorities. OpenID Connect builds on OAuth 2.0, uses JSON and JWT and is usual for modern web applications and mobile apps.

Typical mistakes

An unchecked signature or accepting arbitrary assertions allows identity theft (XML signature wrapping attacks). Always check signature, Audience, Recipient, time window and the uniqueness of the assertion. Use proven libraries instead of parsing XML yourself.

See also: Single sign-on, OpenID Connect, OAuth, Certificate