Use OpenID Connect (OIDC) for new applications, and add SAML 2.0 when your customers’ identity providers require it. OIDC fits web, single-page, mobile and API-first apps with less setup and maintenance. SAML remains the most widely supported option in enterprise, government and higher-education environments, so B2B SaaS products selling to large organizations usually need both.
- Microsoft’s position: Microsoft’s Entra ID guidance recommends defaulting to OIDC for new SaaS development when unsure, and supporting both protocols when your customer base spans both.
- Size: in our test, a signed SAML response was 8.7 times larger than an ID token carrying the same user data (7,340 vs 841 bytes).
- Security reality: both are accepted by US federal identity guidance; the practical risk sits in implementation and libraries, not the protocol choice alone.
- Implementation difficulty (editorial rating): SAML 4/5, OIDC 2/5.
What is the difference between SAML and OIDC?
SAML 2.0 is an XML-based federation standard. The identity provider (IdP) sends the application a digitally signed XML document called an assertion, which states who the user is and carries their attributes.
Get more information: What Is SAML? How SAML Works, How SAML Is Used, and Where It Breaks
OpenID Connect is an identity layer built on OAuth 2.0. The IdP issues a signed JSON Web Token (JWT) called an ID token, which the application validates using public keys it fetches automatically.
SAML vs OIDC comparison table (2026)
| Factor | SAML 2.0 | OIDC |
| Standards body | OASIS | OpenID Foundation |
| First published | 2005 | 2014 |
| Identity payload | XML assertion | JSON Web Token (ID token) |
| Signature method | XML Digital Signature (XML-DSig) | JSON Web Signature (usually RS256) |
| Measured size (same user data) | 7,340 bytes as posted | 841 bytes |
| Transport | Browser redirect or HTTP POST form | OAuth 2.0 Authorization Code flow over HTTPS |
| Connection setup | Manual exchange of metadata, entity IDs, ACS URLs and X.509 certificates | Client reads a discovery URL and configures itself |
| Key maintenance | Signing certificates expire and need coordinated rollover | Keys published at a JWKS endpoint; clients refetch automatically |
| Single-page apps | Poor fit | Native support (Authorization Code + PKCE) |
| Native mobile apps | Workarounds only | Standard pattern |
| Machine-to-machine and AI agents | No role | OAuth 2.0 family handles it |
| User identifier | NameID (often an email) | sub claim (opaque, stable) |
| Debugging | Base64 decode, inflate, and verify XML | Decode three base64url segments |
| Implementation difficulty (editorial) | 4/5 | 2/5 |
- Key dates: SAML 2.0 was approved as an OASIS Standard in March 2005. OIDC Core 1.0 was first published on February 25, 2014; the December 2023 date often quoted is an errata set of clarifications, not a new version.
OIDC’s self-configuration comes from OpenID Connect Discovery: the provider publishes its endpoints and signing algorithms at /.well-known/openid-configuration.
What do a SAML assertion and an OIDC ID token look like?
Both examples describe the same user signing in to the same app. The SAML version is trimmed for readability.
- SAML 2.0 assertion (trimmed)
<saml:Assertion ID="_8e8dc5f69a98" IssueInstant="2026-09-21T10:00:00Z" Version="2.0">
<saml:Issuer>https://idp.example.com</saml:Issuer>
<ds:Signature><!-- SignedInfo, DigestValue, SignatureValue, X.509 certificate --></ds:Signature>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">jane.doe@example.com</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData InResponseTo="_req123"
NotOnOrAfter="2026-09-21T10:05:00Z" Recipient="https://app.example.com/saml/acs"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2026-09-21T09:59:30Z" NotOnOrAfter="2026-09-21T10:05:00Z">
<saml:AudienceRestriction><saml:Audience>https://app.example.com</saml:Audience></saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2026-09-21T10:00:00Z" SessionIndex="_sess456">
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute Name="groups"><saml:AttributeValue>engineering</saml:AttributeValue></saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>Discover more: What Is a SAML Assertion? Structure, Example, and Validation (2026)
- OIDC ID token (decoded payload)
{
"iss": "https://idp.example.com",
"sub": "248289761001",
"aud": "0oa1b2c3d4e5f6g7h8i9",
"iat": 1789984800,
"exp": 1789985100,
"nonce": "n-0S6_WzA2Mj3kLm",
"amr": ["pwd", "otp"],
"email": "jane.doe@example.com",
"groups": ["engineering", "sso-admins", "all-staff"]
}What to notice:
- SAML carries its validity rules inside the document (Conditions, Audience, Recipient), and each must be checked alongside the XML signature.
- The ID token’s signature sits in a separate JWT header and signature segment, so the payload stays compact and readable.
- The user identifier differs: an email NameID in SAML, an opaque sub in OIDC. The field-by-field mapping is in the migration section.
How much larger is a SAML response than an OIDC ID token?
About 8.7 times larger in our test. We built and cryptographically verified a signed SAML response and an RS256-signed ID token carrying identical user data, then measured both.
The XML signature block alone (2,213 bytes) is more than 2.5 times the size of the entire ID token.
| Measurement | Bytes |
| SAML response, raw XML | 5,504 |
| Of which: XML signature block (including embedded X.509 certificate) | 2,213 (40%) |
| SAML response, base64-encoded as sent in the SAMLResponse form field | 7,340 |
| OIDC ID token, compact JWT | 841 |
| Of which: header / payload / signature (base64url) | 62 / 435 / 342 |
- Test setup: one user with five attributes (email, given name, family name, display name, and three groups); RSA-2048 key; SHA-256; exclusive XML canonicalization; signed assertion with embedded certificate. Built with the open-source signxml and PyJWT libraries, September 2026.
- What changes the numbers: in our test, each single-value SAML attribute took about 280 bytes of XML (with namespace declarations repeated per value, as some IdPs emit them), while the same claim took about 20 bytes of JSON in the ID token. Signing the whole response and the assertion separately roughly adds another signature block.
- Why it matters: SAML responses travel through the browser as form posts, so large group lists can hit proxy, load-balancer or web-server size limits. OIDC tokens in the code flow move server-to-server.
How do SAML and OIDC login flows work?
In SAML, the signed assertion travels through the browser. In OIDC’s Authorization Code flow, the browser carries only a one-time code and tokens are exchanged server to server.
- SAML SP-initiated login
- User opens the app (the service provider, or SP).
- The SP redirects the browser to the IdP with a SAML AuthnRequest.
- The user signs in; the IdP posts a signed SAMLResponse back to the SP’s Assertion Consumer Service (ACS) URL.
- The SP verifies the XML signature, checks conditions and audience, and creates a session.
- OIDC Authorization Code + PKCE login
- The app (relying party) redirects the user to the IdP with scope=openid, state, nonce and a PKCE code_challenge.
- The user signs in; the IdP redirects back with a short-lived authorization code.
- The app exchanges the code plus the code_verifier at the token endpoint (a back-channel call).
- The app validates the ID token’s signature, iss, aud, exp and nonce, then creates a session.
The key structural difference: in SAML the identity proof travels through the browser; in OIDC’s code flow, the browser only carries a one-time code.
When should you use SAML vs OIDC?
Four questions decide most SAML vs OIDC choices. Non-human callers use OAuth 2.0, research federations require SAML, and mixed customer bases need both.
- Use SAML when
- An enterprise customer’s security review or procurement contract specifies SAML.
- The customer’s IdP only supports SAML (older ADFS setups, some on-prem products).
- You are joining a research, education or government federation built on SAML metadata.
- You already have a working, patched SAML integration and no mobile or SPA requirement.
- Use OIDC when
- You are building a new web app, SPA, mobile app or API-first service.
- You need consumer or social login (Google, Microsoft, Apple accounts).
- You want self-service onboarding, where customers paste a discovery URL instead of exchanging certificates.
- The same identity must also authorize API calls, since OIDC and OAuth share one token infrastructure.
- Support both when
- You sell B2B SaaS to a mixed customer base. The common pattern is an identity broker or auth platform that accepts SAML from the customer’s IdP and gives your app one consistent OIDC session.
Which is better, SAML or OIDC, for your application type?
| Application type | Recommended | Reason |
| New B2B SaaS (multi-tenant) | OIDC, plus SAML on request | OIDC for your own stack; SAML to close enterprise deals |
| Internal corporate web app | Either; follow the IdP’s default | Both are fully supported in Entra ID and Okta |
| Consumer web app | OIDC | Social IdPs use OIDC |
| Single-page app (React, Angular, Vue) | OIDC | Authorization Code + PKCE is built for browser clients |
| Native iOS or Android app | OIDC | RFC 8252 defines the native-app pattern |
| APIs and microservices | OIDC + OAuth 2.0 | JWTs validate locally with published keys |
| AI agents and service accounts | OAuth 2.0 | Interactive SAML and OIDC logins do not apply to non-human callers |
| University or research federation | SAML | Federations exchange SAML metadata |
| Legacy on-prem app with SAML plugin only | SAML | No rebuild needed |
Is OIDC more secure than SAML?
Neither protocol is insecure by design, but SAML’s XML signature processing produced more critical authentication bypasses in 2025. OIDC failures cluster around applications skipping token validation steps. NIST SP 800-63C-4 recognizes both protocols as valid at every federation assurance level.
Where does SAML fail?
- XML Signature Wrapping: the signature checks one element while the app reads identity from another.
- Parser differentials: two XML parsers in the same library interpret one document differently.
- Canonicalization tricks: XML normalization lets altered content still pass the signature check.
- IdP-initiated SSO: unsolicited responses carry no InResponseTo value, so the SP cannot bind the response to a request. See the OWASP SAML Security Cheat Sheet.
Where does OIDC fail?
- Algorithm confusion: a library accepts an HMAC-signed token verified with the server’s public key.
- alg: none acceptance: a library treats an unsigned token as valid.
- Missing claim checks: skipping aud, iss, exp or nonce validation.
- Legacy implicit flow: tokens returned in the URL fragment can leak. RFC 9700 (OAuth 2.0 Security Best Current Practice) says clients should not use it.
Which SAML vulnerabilities were disclosed in 2025?
| CVE | Component | Impact | Fix |
| CVE-2025-25291, CVE-2025-25292 | ruby-saml up to 1.17.0 | Forged assertions, login as any user | Upgrade to 1.18.0 |
| CVE-2025-23369 | GitHub Enterprise Server (libxml2 behavior) | SAML authentication bypass | Vendor patch |
| CVE-2025-66567, CVE-2025-66568 | ruby-saml 1.12.x branch up to 1.12.4 | Signature wrapping via incomplete earlier fix | Upgrade to 1.18.0 |
- GitHub Security Lab reported that an attacker holding one valid signature made with the organization’s SAML validation key could build their own assertions and sign in as any user.
- The flaw came from ruby-saml using REXML to extract the signature while using Nokogiri to canonicalize the signed content.
- A later advisory confirmed the fix for CVE-2025-25292 was incomplete, again because the two parsers can build different document structures from the same input.
- PortSwigger’s December 2025 research concluded that lasting remediation requires significant restructuring of SAML libraries, and reported Okta’s January 2026 position that service providers should address the issue through patching.
Security checklist for either protocol
- Use a maintained library or identity platform; never hand-parse XML or JWTs.
- Subscribe to security advisories for your SAML or JWT library and patch within your critical-fix window.
- SAML: prefer SP-initiated flows, require signed assertions, reject responses without a matching InResponseTo, and keep assertion validity short.
- OIDC: use Authorization Code + PKCE, pin allowed algorithms, and validate iss, aud, exp and nonce on every token.
- Decode production tokens locally, not on third-party websites.
Do SAML and OIDC support MFA and passkeys?
Yes, both do, because MFA and passkeys happen at the identity provider, not in the protocol. The protocol reports how the user authenticated, so your app can require stronger sign-in for sensitive actions.
| Capability | SAML 2.0 | OIDC |
| Where the method is reported | AuthnContextClassRef inside AuthnStatement | acr claim (assurance level) and amr claim (methods used) |
| How the app requests a stronger method | RequestedAuthnContext in the AuthnRequest | acr_values parameter in the authorization request |
| Forcing a fresh sign-in | ForceAuthn=”true” | prompt=login or max_age |
| Standard method values | Authentication context class URNs | RFC 8176 registry (for example pwd, otp, hwk) |
- Your app must check the returned value; requesting MFA without verifying the response is a common gap in both protocols.
- IdPs differ in which values they emit, so test against each customer’s IdP rather than assuming a standard string.
SAML vs OIDC vs OAuth: what is the difference?
SAML and OIDC authenticate users. OAuth 2.0 authorizes access to resources and does not, on its own, prove who the user is.
| Protocol | Job | Output |
| SAML 2.0 | Authentication and federation | Signed XML assertion |
| OIDC | Authentication on top of OAuth 2.0 | ID token (JWT) + OAuth access token |
| OAuth 2.0 | Delegated authorization | Access token (format not mandated) |
OIDC vs OAuth 2.0
- OIDC adds four things to OAuth 2.0: the openid scope, the ID token, the UserInfo endpoint, and standardized discovery.
- Using a plain OAuth access token as proof of login is an anti-pattern, because the token was issued for an API, not for your app.
- The OAuth 2.1 draft is intended to replace and obsolete RFC 6749; it removes the Implicit and Resource Owner Password Credentials grants and makes PKCE mandatory for all clients (OAuth 2.1 Internet-Draft). As of this review, it is still an Internet-Draft, not a published RFC.
SAML vs OAuth
- They solve different problems, so they are not direct substitutes.
- They can work together: an app can accept SAML for login and then call APIs with OAuth access tokens, including by exchanging a SAML assertion for an OAuth token (the SAML 2.0 Bearer Assertion grant).
Explore more: SAML vs OAuth: What Is the Difference and Which Should You Use in 2026?LDAP
SAML vs OIDC vs SCIM vs LDAP: which layer does each protocol handle?
SAML and OIDC compete only in the authentication layer. LDAP stores users, SCIM provisions accounts, and OAuth handles authorization and agent access.
| Layer | Question answered | Protocol | Format |
| Directory | Where are user records stored and queried? | LDAP | Binary (BER) over TCP |
| Provisioning | How are accounts created, updated and removed in the app? | SCIM 2.0 | JSON over REST |
| Authentication (SSO) | Who is signing in right now? | SAML 2.0 or OIDC | XML or JWT |
| Authorization | What may this client access? | OAuth 2.0 | Access tokens |
| Workload and agent identity | Which service or agent is calling, on whose behalf? | OAuth 2.0 client credentials, RFC 8693 Token Exchange | JWTs |
- SAML vs OIDC vs SCIM: SCIM (RFC 7644) never signs anyone in; it keeps app accounts in sync. SSO without SCIM blocks new logins for a disabled user but leaves their app account, data and any issued API tokens in place until someone removes them.
- SAML vs OIDC vs LDAP: LDAP (RFC 4511) is a directory access protocol, not web SSO. An app using LDAP bind receives the user’s password directly; SAML and OIDC apps never see it.
- Typical enterprise stack: Active Directory (LDAP) as the source, Entra ID or Okta as the IdP, SAML or OIDC for login, SCIM for lifecycle, OAuth for APIs.
See more details: SAML vs LDAP: What Is the Difference, and Which Should You Use in 2026?OIDC
How do SAML and OIDC differ in Microsoft Entra ID and Okta?
SAML setup centers on entity IDs, ACS URLs and an expiring certificate. OIDC setup centers on a redirect URI, a client ID and a discovery URL with rotating keys.
| Item | Microsoft Entra ID | Okta |
| Where you choose | SAML: Enterprise applications > Single sign-on. OIDC: App registrations | Applications > Create App Integration > Sign-in method |
| Sign-in method options | SAML, OIDC, password-based, linked | OIDC, SAML 2.0, SWA, API Services |
| User identifier in OIDC | sub is unique per app; oid is stable across apps | sub is the user’s Okta user ID |
| SAML signing keys | Certificates expire and must be rolled over | Managed in the app’s Sign On tab |
| SAML testing aid | Built-in “Test” option in the SSO settings | “Preview the SAML Assertion” in the wizard |
Entra ID details that affect your design:
- Entra’s sub claim is a pairwise identifier: one user signing into two apps with different client IDs produces two different sub values, while the oid claim stays the same across applications (Entra ID token claims reference). If several of your apps must recognize the same user, key on oid plus tid.
- SAML signing certificates in Entra ID have an expiry date, and a missed rollover breaks sign-in for every user of that app. Track them per Microsoft’s certificate management guide.
Okta details that affect your design:
- Okta’s SAML setup has you select SAML 2.0 as the sign-in method, enter SAML settings, and optionally preview the XML assertion those settings generate.
- For OIDC, the application type you pick (web, single-page, native) sets the allowed grant types, so choose it to match your client.
What breaks when you migrate from SAML to OIDC?
The most common failure is account duplication: the user identifier changes, so returning users look like new users.
SAML to OIDC field mapping
| SAML element | OIDC equivalent | Migration note |
| NameID | sub | Values differ. Do not assume an email NameID equals sub |
| Issuer | iss | Update trusted issuer per tenant |
| AudienceRestriction | aud | Becomes your OIDC client ID |
| NotOnOrAfter | exp | Token lifetime moves to IdP token policy |
| IssueInstant | iat | Direct equivalent |
| InResponseTo | nonce + state | Replay and CSRF binding |
| AuthnContextClassRef | acr / amr | Re-map any MFA enforcement rules |
| AttributeStatement | Claims (email, name, groups) | Re-create custom attribute mappings as claims |
| SessionIndex + Single Logout | sid + RP-initiated or back-channel logout | Logout behavior must be retested |
- Migration checklist
- Export every SAML attribute and group mapping currently in use, per customer connection.
- Pick the long-term user key (in Entra ID, oid + tid; in Okta, sub). Never key on email alone, because emails change and get reassigned.
- Link existing accounts once: match the verified email from the first OIDC login to the existing record, then store the new stable identifier.
- Run SAML and OIDC side by side and switch one customer tenant at a time.
- Check group claim limits: Entra ID replaces the groups list with an overage indicator when a user belongs to too many groups (200 for JWTs, 150 for SAML), so large-group customers may need Microsoft Graph lookups.
- Retest logout, session timeout and MFA step-up before removing the SAML connection.
Is OIDC replacing SAML?
No. OIDC is the default for new builds, but SAML will coexist for years because of its installed base.
- OIDC Core was published as ISO/IEC 26131:2024, and OpenID Federation reached Final Specification in February 2026, giving OIDC a multi-party trust model that used to be a SAML advantage (ISO/IEC 26131:2024; OpenID Federation 1.0 final approval).
- SAML 2.0 has no successor version in development; it is maintained, not evolving.
- Practical outlook: enterprise buyers will keep asking “Do you support SAML?” while accepting OIDC more often, especially from Entra ID and Okta tenants that support both.
Does your region change the SAML vs OIDC decision?
For most commercial SaaS, no. Two regional ecosystems do change it.
Research and education federations run on SAML worldwide. eduGAIN, operated by GÉANT, interconnects national research and education federations so a service trusted in one country can accept users from others. These federations use the SAML V2.0 Web Browser SSO profile, and services must register SAML metadata to join.
| Market | Research and education federation | Protocol |
| United States | InCommon | SAML 2.0 |
| Canada | Canadian Access Federation | SAML 2.0 |
| Australia | AAF | SAML 2.0 |
| India | INFED | SAML 2.0 |
| Europe | National federations (for example DFN-AAI in Germany) | SAML 2.0 |
All five are eduGAIN participants. If you sell to universities or research institutions in any of these markets, SAML support is effectively mandatory.
The EU digital identity wallet uses OpenID-family protocols. The specifications selected for the eIDAS 2.0 Architecture Reference Framework are OpenID for Verifiable Presentations (OpenID4VP) 1.0 Final, OpenID for Verifiable Credential Issuance (OpenID4VCI) 1.0 Final, and the High Assurance Interoperability Profile (HAIP) 1.0. These are credential-presentation protocols, not classic OIDC login, but EU relying parties already on the OAuth and OIDC stack have a shorter path to accepting wallet credentials.
View more details: SAML vs SSO: Is SAML the Same as Single Sign-On?
Frequently asked questions
Can SAML and OIDC be used together?
Yes. An identity broker (Entra ID, Okta, Auth0 and similar platforms) can accept a customer’s SAML login and issue your app an OIDC session. Your app then maintains one OIDC integration regardless of each customer’s protocol.
Is SAML used for authentication or authorization?
Mainly authentication plus user attributes. SAML defines authorization-decision statements, but most deployments leave authorization to the app, using group or role attributes from the assertion.
How do you debug SAML and OIDC logins?
For SAML, capture the browser POST with a SAML tracer extension, then base64-decode it and inspect Conditions, Audience and the signature. For OIDC, decode the ID token’s three segments locally and check iss, aud, exp and nonce against your configuration.
Methodology: Payload sizes were measured on September 21, 2026 using equivalent SAML and OIDC artifacts generated and signature-verified with the open-source signxml and PyJWT libraries. Setup fields reflect the Microsoft Entra ID and Okta admin consoles as documented in September 2026. Last reviewed: September 23, 2026.
