What is the difference between SAML and OIDC?

Both enable single sign-on. SAML 2.0 is a 2005 OASIS standard that passes signed XML assertions through the browser and dominates enterprise SSO. OpenID Connect is a JSON and JWT identity layer built on OAuth 2.0, favored for new web, mobile and API-centric apps, and it pairs naturally with OAuth access tokens for APIs.

SAML 2.0 (Security Assertion Markup Language) is an XML-based OASIS standard, approved in 2005, for exchanging authentication and attribute data between an identity provider and a service provider. The identity provider signs an assertion saying who the user is, and the application trusts it to create a session.

Which should I choose for a new application?

Use OIDC for your own sign-in, mobile apps and APIs. Add SAML as a service provider if you sell to enterprises, because their identity providers and procurement checklists still expect it. Most B2B SaaS products end up supporting both.

Is OIDC more secure than SAML?

Neither protocol is broken, but SAML implementations have a worse record. Validating XML signatures correctly is hard, and signature wrapping and parser differentials produced repeated bypasses, including ruby-saml CVE-2025-25291 and CVE-2025-25292 and FortiCloud SSO CVE-2025-59718. OIDC's equivalent failures are JWT validation errors, which a maintained library with pinned algorithms mostly closes.

Do SAML and OIDC handle provisioning?

No. Federation gets a user signed in; it does not create, update or remove the account. SCIM 2.0 (RFC 7643 and RFC 7644) handles provisioning, and enterprise buyers usually ask for SSO and SCIM together.

Can an AI agent use SAML?

Not directly, since SAML has no token an agent can present to an API. The ID-JAG draft (Cross App Access) lets a client that signed a user in with SAML exchange the assertion at the identity provider for OAuth tokens, so SAML estates can still feed agent authorization.

SAML vs OIDC: Which SSO Protocol Should You Use in 2026?

Q: Is SAML still used in 2026?

Yes. SAML remains the default for enterprise and B2B SSO. In SWI's 2026 Phishing-Resistant MFA Support Matrix, 83 of 95 business SaaS apps offered SAML and 30 offered OpenID Connect, so most identity platforms support both.

SAML vs OIDC verdict: use OpenID Connect for new web, mobile and API sign-in, and support SAML 2.0 wherever enterprise customers or workforce SaaS require it. Both protocols do single sign-on. SAML 2.0 is a 2005 OASIS standard that passes signed XML assertions through the browser; OIDC is a JSON and JWT identity layer on OAuth 2.0. Most teams end up running both.

The reason both survive is market share, not taste. In SWI's Phishing-Resistant MFA Support Matrix, 83 of 95 business SaaS apps (87%) offered SAML and 30 (32%) offered OpenID Connect; 58 offered SAML only and 5 OIDC only.

SAML vs OIDC side by side

	SAML 2.0	OpenID Connect
Standards body and status (November 2026)	OASIS Standard since 2005, stable	OpenID Foundation Final, errata set 2 (December 2023); ISO/IEC 26131:2024
Data format	XML assertions, XML Signature	JSON, signed JWT ID token
Transport	Browser redirects and auto-posted forms	Redirects plus back-channel token request
Native mobile and SPA fit	Poor	Good, with PKCE
API access	None; no token for APIs	Pairs with OAuth access tokens
Setup	Metadata XML exchange, certificate pinning	Discovery URL plus client registration
Typical home	Workforce SSO into SaaS, B2B federation	Consumer login, mobile, modern SaaS, AI agents
Common failure	Signature wrapping, parser differentials	JWT validation errors

SAML 2.0

SAML is an XML-based standard, deeply entrenched in enterprise web SSO. The identity provider authenticates the user and posts a signed assertion to the application's Assertion Consumer Service URL; the application validates it and creates a session. If you sell to enterprises, you will be asked for SAML, because that is what their identity providers and procurement checklists speak. See the SAML 2.0 standard page for an SP-initiated login step by step and the full validation checklist.

OpenID Connect (OIDC)

OIDC is a modern identity layer built on OAuth 2.0, using JSON and JWTs. It is the better fit for mobile apps, single-page apps, and APIs, with simpler tokens and a cleaner developer experience. OIDC discovery lets a client self-configure from one well-known URL, which is why new integrations are faster.

How to choose

Your situation	Use
Your own web or mobile app sign-in	OIDC
Your API, or AI agents calling it	OAuth 2.0 with OIDC for the user
Selling to enterprises that bring their own IdP	Accept SAML and OIDC as a service provider
Connecting workforce SaaS to your IdP	Whatever the app supports, usually SAML
Legacy on-premises apps	SAML, or a gateway that speaks it

Most CIAM and IAM platforms support both, so the real question is which your counterparties require.

The security difference nobody mentions

SAML's security record is worse than OIDC's, and the reason is structural rather than reputational. Validating an XML signature correctly is hard: canonicalization, parser differentials between the library that validates and the library that reads, and assertion wrapping have produced a long run of bypasses where a service provider accepted a forged assertion as valid. The SWI identity CVE catalog shows the pattern:

Parser differentials in ruby-saml. CVE-2025-25291 and CVE-2025-25292 let an attacker with one valid signed assertion log in as any user. The fix did not end it: CVE-2025-66567, disclosed December 8, 2025, still allowed forgery below ruby-saml 1.18.0.
Encrypted assertion paths. CVE-2024-4985 let a forged response through GitHub Enterprise Server when encrypted assertions were enabled.
Appliance SSO. CVE-2025-59718 let a crafted SAML message bypass FortiCloud SSO; attackers logged in as FortiGate admins and exported configurations from December 12, 2025 (incident record). In January 2026 a follow-on flaw, CVE-2026-24858, hit devices already patched.
Calling code that asks the wrong question. In August 2026 attackers exploited the miniOrange SAML plugin for WordPress, where a loose boolean check on PHP's openssl_verify() read the error value -1 as success. The cryptography worked; the code did not.
Forging at the source. If an attacker steals the IdP's signing key, every service provider accepts their assertions: federation trust abuse and SAML forgery, often called Golden SAML.

If you operate a SAML service provider: use a maintained library and patch it, compare verification results exactly, reject unexpected signature algorithms, pin the expected signing certificate from metadata, and check that the assertion is addressed to you, is recent, answers a request you sent, and has not been replayed.

OIDC is not immune. Its failures are JWT validation errors: accepting alg: none (CVE-2023-29357 in SharePoint), confusing HMAC and RSA, skipping the audience check, or not checking the signature at all, as in the SimpleHelp OIDC token forgery of 2026. A maintained JWT library with pinned algorithms closes most of them, while XML signature validation has more places to go wrong.

Practical implementation notes

You will support both. Any B2B SaaS selling upmarket needs SAML because enterprise buyers require it, and OIDC because that is what your own application uses.
SCIM is a separate question. SCIM 2.0 handles provisioning, and enterprise buyers usually ask for SSO and SCIM together.
Metadata and certificate rotation are the operational tasks that break SAML integrations in production. Automate metadata refresh where the partner supports it, and calendar every signing certificate expiry.
Prefer SP-initiated flows. IdP-initiated SAML has no request to match InResponseTo against, which widens replay and injection risk.
Agents and SAML. The ID-JAG draft lets a client exchange a SAML assertion at the IdP for OAuth tokens, so a SAML estate is not a dead end for AI agent access.

Tools that add SAML and OIDC for you

For B2B SaaS teams, per-connection pricing dominates. On October 30, 2026 the Identity Pricing Transparency Index read WorkOS SSO and Directory Sync at $125 per connection, and SSOJet at $59 per connection per month billed annually with a two-connection minimum. Auth0, FusionAuth and Keycloak also federate both ways; see the best SSO and SCIM platforms for B2B SaaS. On the workforce side, Okta, Microsoft Entra and Ping Identity act as IdP for both protocols.

Where to start

See the SSO implementation guide, the identity federation implementation guide, and OAuth vs OIDC for the OAuth relationship.