SAML vs OIDC — which should I use?

Use whichever the application supports best. Older enterprise software usually offers SAML, while modern web and mobile applications favor OIDC, which is lighter and JSON-based. Most organizations run both side by side from the same identity provider, so this is rarely an either-or decision.

SAML is mature rather than obsolete. New consumer-facing development has largely moved to OIDC, but SAML remains the required protocol for a huge share of enterprise and government software. Expect to support it for the foreseeable future.

What is a SAML assertion?

It is the signed XML document the identity provider sends to the application after authenticating a user. It states who the user is, when and how they authenticated, and optionally includes attributes like email and group memberships. The application trusts it because the digital signature proves it came from the configured IdP.

SAML (Security Assertion Markup Language)

What is SAML (Security Assertion Markup Language)?

SAML is an XML-based standard that lets an identity provider pass signed authentication assertions to applications, enabling enterprise SSO.

Last updated: 13 July 2026

How SAML works

SAML defines two roles: the identity provider (IdP), which authenticates users, and the service provider (SP), which is the application the user wants to reach. When a user opens the application, the SP redirects the browser to the IdP with an authentication request. The IdP verifies the user, then posts back a SAML assertion, an XML document that states who the user is and when they authenticated.

The assertion is digitally signed with the IdP certificate, and the SP validates that signature against metadata exchanged during setup. Assertions can also carry attributes such as email, groups, and roles, which the application uses to authorize the user. The whole exchange happens through browser redirects, so the SP and IdP never need a direct network path to each other.

Why SAML matters

SAML 2.0, finalized in 2005, became the backbone of enterprise single sign-on and remains deeply embedded in business software. Thousands of SaaS products, government systems, and internal enterprise applications expose SAML as their primary or only federation option, so any serious identity platform must speak it fluently.

For security teams, SAML removes application-local passwords and centralizes authentication policy at the IdP. For vendors, supporting SAML is often the gate to enterprise sales, since procurement checklists routinely require it. Although newer applications increasingly prefer OpenID Connect, SAML will remain essential for interoperability for years to come.

SAML in practice

Setting up a SAML integration means exchanging metadata between the IdP and the SP: entity IDs, endpoint URLs, and signing certificates. Most identity platforms ship pre-built connectors for popular applications that reduce this to a few fields. Attribute mapping deserves care, since applications differ in how they expect names, emails, and group claims to arrive.

Operationally, the most common failure modes are expired signing certificates, clock skew between systems, and mismatched name ID formats, so certificate rotation and monitoring belong in the runbook. Monosign implements SAML 2.0 in both roles, acting as IdP for applications and as SP when federating with external identity sources.

Frequently asked questions

SAML vs OIDC — which should I use?: Use whichever the application supports best. Older enterprise software usually offers SAML, while modern web and mobile applications favor OIDC, which is lighter and JSON-based. Most organizations run both side by side from the same identity provider, so this is rarely an either-or decision.
Is SAML outdated?: SAML is mature rather than obsolete. New consumer-facing development has largely moved to OIDC, but SAML remains the required protocol for a huge share of enterprise and government software. Expect to support it for the foreseeable future.
What is a SAML assertion?: It is the signed XML document the identity provider sends to the application after authenticating a user. It states who the user is, when and how they authenticated, and optionally includes attributes like email and group memberships. The application trusts it because the digital signature proves it came from the configured IdP.