SAML vs OIDC: what's the difference, and which should you use?

SAML 2.0 and OpenID Connect (OIDC) solve the same core problem: a user signs in once at an identity provider (IdP), and applications trust the IdP's statement about who they are. The difference is in how that statement is packaged and carried, and that decides where each one fits.

Short version: use OIDC for anything you build; support SAML because enterprise customers and SaaS tools will ask for it.

At a glance

How a SAML login works

1. The user opens the app (the SP). It builds a signed or unsigned AuthnRequest and redirects the browser to the IdP.
2. The user signs in at the IdP.
3. The IdP returns an HTML form that auto-posts a SAML response to the SP's Assertion Consumer Service (ACS) URL. It contains an assertion signed with the IdP's certificate: the user's NameID, attributes (email, groups) and validity window.
4. The SP checks the signature against the certificate from the IdP's metadata, checks audience and timestamps, and creates a session.

Everything goes through the browser. The SP never calls the IdP directly, which is why SAML works with apps that sit on networks the IdP can't reach.

How an OIDC login works

1. The app redirects the browser to the IdP's authorization endpoint with its client ID, redirect URI, scopes (openid profile email) and a PKCE challenge.
2. The user signs in and consents.
3. The IdP redirects back with a short-lived authorization code.
4. The app's backend exchanges the code at the token endpoint for an ID token (a JWT with the user's identity), an access token and optionally a refresh token.
5. The app validates the ID token's signature using the IdP's published keys (JWKS), and can call the UserInfo endpoint or your APIs with the access token.

Because the tokens come over a direct back-channel call, nothing sensitive sits in the browser's history, and the same flow works for native and single-page apps with PKCE.

Which should you use?

Choose OIDC when:

• You're building the app, whether web, mobile, desktop or CLI.
• The app also needs to call APIs on the user's behalf.
• You want libraries in every language and a five-minute setup from a discovery URL.
• You're authorizing AI agents and MCP servers, which build on OAuth (more on that).

Choose SAML when:

• You're connecting to a SaaS product that only offers SAML SSO, or offers it on its enterprise plan.
• A customer's IT team requires it, which is common in B2B: "Does your app support SAML SSO?" is a standard procurement question.
• An existing app already speaks SAML and works.

In practice you need both. Your identity provider should be a SAML IdP for the SaaS tools your employees use and an OIDC provider for your own apps, and, if you sell B2B software, accept your customers' SAML or OIDC IdPs as upstream login providers.

Security notes

• SAML: most real-world vulnerabilities are in XML signature validation (signature wrapping, accepting unsigned assertions, comments in NameIDs). Use a well-maintained library and don't parse assertions yourself.
• OIDC: use the authorization code flow with PKCE, validate iss, aud, exp and nonce, and don't use the implicit flow for new apps.

One IdP for both

Casdoor is an open-source identity provider that is both a SAML 2.0 IdP (with metadata, signed assertions and single logout) and an OpenID Connect provider (discovery, JWKS, PKCE, refresh tokens, RP-initiated and back-channel logout), plus CAS, LDAP and RADIUS for older apps. It can also log users in through upstream SAML and OIDC providers such as Entra ID, Okta or Google Workspace.

See the SAML and SSO pages for details, self-host it for free, or run it on Casdoor Cloud from $24/month billed yearly.

FAQ

Is OIDC replacing SAML? For new applications, largely yes. SAML isn't going away soon, though: enterprise SaaS products and corporate IT still depend on it.

Is OIDC more secure than SAML? Neither is inherently more secure. OIDC is easier to implement correctly, because JSON and JWT validation have fewer pitfalls than XML signatures.

Can an app support both? Yes. Many B2B apps let each customer choose SAML or OIDC for their SSO connection. Behind the scenes, a broker such as Casdoor can accept either and hand your app the same OIDC tokens.

What about OAuth 2.0? OAuth 2.0 is about authorization: giving an app an access token to call an API. OIDC adds an identity layer on top of OAuth 2.0 (the ID token and UserInfo), which is what makes it a login protocol.