Security Assertion Markup Language (SAML) is an open standard that lets one system sign users in on behalf of others. The system that checks the user’s identity, the identity provider (IdP), sends the application a digitally signed XML message, called an assertion, stating who the user is and when and how they authenticated. The application trusts that assertion instead of asking for its own password. SAML 2.0, maintained by the OASIS standards body, is one of the main protocols behind enterprise single sign-on (SSO).
At a glance
- An XML-based standard for exchanging signed authentication statements between an identity provider and an application.
- The application is called the service provider (SP); it trusts signed SAML messages from the IdP after checking them.
- Widely supported by business SaaS and browser-based applications.
- Assertions can carry attributes such as email, department or group, which the app can use to decide permissions.
- Handles sign-in, not account provisioning, and relies on signing certificates that must be renewed before they expire.
What problem it solves
Without federation, every application keeps its own passwords. Users reuse them, IT can’t enforce multi-factor authentication (MFA) consistently, and removing a leaver means visiting each app. SAML lets applications hand authentication to a central identity provider, so users sign in once with whatever methods policy requires, and disabling one identity blocks new sign-ins to every SAML-connected app. Sessions already open in an application may continue until they expire, unless the app supports logout or session revocation, so buyers should also check each app’s session lifetime, automated deprovisioning (often through SCIM) and revocation support.
For the application owner, SAML also means not storing user passwords at all for those users, which removes one category of breach risk.
How it works
Trust setup. The identity provider and the service provider exchange metadata: each other’s URLs, identifiers and the IdP’s public signing certificate. This is usually done once by an administrator, often from a pre-built app template in the identity provider.
Service provider-initiated sign-in. A user opens the application. It sees no session and redirects the browser to the IdP with an authentication request.
Authentication at the IdP. The IdP signs the user in, applying password, MFA, passwordless or conditional access policies, or reuses an existing IdP session.
The assertion. The IdP returns a SAML response, carried by the user’s browser, containing an assertion that names the user, says when and how they authenticated and often includes attributes. Depending on the profile and configuration, the IdP signs the response, the assertion or both with its private key, and may also encrypt the assertion.
Validation. The service provider validates the required XML signatures against the IdP’s certificate, then checks the issuer, the audience (that the assertion is meant for this app), the recipient or destination address and the validity time window before starting a session. What the user may do inside the app is decided by the app, often using attributes from the assertion.
Identity provider-initiated sign-in. Users can also start from the IdP’s app portal, which sends an assertion directly to the app.
Certificates and lifecycle. Signing certificates have expiry dates. When one is renewed, connected applications need the new certificate, or sign-in fails. Account creation and removal are handled separately, commonly with SCIM provisioning.
When it matters for buyers
- When buying SaaS. Confirm SAML or OpenID Connect support, and automated provisioning, on the plan you are buying; many vendors reserve them for higher tiers.
- When rolling out an identity provider. The number of apps with ready-made SAML integrations affects effort and timeline.
- When reviewing SaaS sprawl. SaaS management platforms can show which apps sit outside SSO.
- When certificates are due to expire. Track IdP signing certificates and coordinate renewals with app owners.
- When access controls depend on attributes. If the app assigns roles from SAML attributes, those attributes need to be accurate and governed.
Questions to ask vendors
- Do you support SAML 2.0 and OpenID Connect, and on which plans?
- Do you support service provider-initiated and identity provider-initiated sign-in?
- Can SAML be enforced for all users, with a limited break-glass local login for admins?
- Which attributes can you map to roles or groups in your application?
- Do you support automated provisioning and deprovisioning, for example through SCIM?
- How long do application sessions last after SAML sign-in, and can they be revoked when we disable a user?
- How do you handle signing certificate rollover without downtime?
How it differs from SSO, OAuth 2.0 and OpenID Connect
SSO is the outcome, signing in once to reach many applications; SAML is one way to deliver it. OpenID Connect (OIDC) delivers the same outcome with a different design: it is an identity layer built on OAuth 2.0 that uses JSON-based ID tokens and is common in modern web and mobile apps. OAuth 2.0 on its own is an authorization framework: it lets an application obtain an access token to call an API, for example to read a calendar on a user’s behalf, but it does not by itself tell the application who the user is. SAML and OIDC are authentication and federation standards; OAuth is about delegated access. All of these sit within identity and access management (IAM). Many secure service edge services also rely on SAML or OIDC with your IdP to identify users before granting access.