Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization data between an identity provider and a service provider, enabling single sign-on across enterprise applications.

‍

Main takeaways

• SAML is the foundation of most enterprise SSO implementations—it allows users to authenticate once with their identity provider and access multiple applications without re-entering credentials.
• Applications integrated via SAML are governed through the IdP: access can be centrally provisioned, MFA enforced, sessions managed, and access revoked from a single control point.
• SAML governs only the applications it's configured to protect. Shadow SaaS, personal accounts, and applications employees access with local credentials fall entirely outside SAML's reach.
• SAML assertions carry user attributes—role, group membership, email—that receiving applications use for access decisions. Misconfigured attribute mapping is a common source of over-permissioned access.
• SAML has largely been complemented by OIDC for modern consumer-style and developer-facing SSO flows, but remains the dominant standard for enterprise B2B application integrations.

What is SAML?

Before SSO standards like SAML, enabling centralized authentication across enterprise applications meant either maintaining shared credential databases—a security and operational nightmare—or building bespoke integration work for every application pair. SAML introduced a federated model that solved this at scale: a trusted third party, the identity provider, vouches for the user's identity by issuing a cryptographically signed assertion. The receiving application, the service provider, trusts that assertion without needing to manage or verify credentials itself.

‍

The result is the enterprise SSO experience most employees take for granted: one login through Okta, Microsoft Entra, or Google Workspace that opens access to dozens of connected applications. Behind that experience, SAML assertions are being generated, transmitted, and validated with each authentication event.

‍

How SAML works

A typical SAML SSO flow:

1. The user attempts to access a service provider (a SaaS application).
2. The service provider, which doesn't manage its own credentials, redirects the user to the configured identity provider.
3. The identity provider authenticates the user—through password, MFA, or an existing session.
4. The identity provider generates a SAML assertion: a signed XML document containing the user's identity, attributes, and authentication status.
5. The assertion is transmitted to the service provider, which validates the signature and grants access based on the included attributes.

The service provider never sees the user's credentials. Trust is established through the IdP's digital signature, which the service provider verifies against the IdP's published certificate.

‍

The SAML coverage gap

SAML governance is only as broad as the set of applications configured to use it. Applications that don't support SAML, haven't been integrated with the IdP, or that employees access through personal email addresses or direct signups operate entirely outside SAML's governance scope.

‍

In practice, most organizations have SAML coverage over their core, IT-managed applications and significant blind spots in everything else. Shadow SaaS applications adopted by employees independently will never appear in the IdP's application catalog. Personal accounts used for work—a Slack workspace someone set up for a project, a Figma account connected to a personal Gmail—generate no SAML assertions and receive no SAML-based governance.

‍

Learn how Nudge Security surfaces SaaS access beyond the IdP's field of view →