What actually keeps a stolen password from becoming a stolen payroll account? Most people assume the answer is the login protocol their company picked, whether that is OIDC or SAML. That assumption is half right, and the wrong half is where breaches live.
Both standards solve one problem well: proving who a user is without handing every app their password. Neither one stops phishing, malware on a laptop, or a session cookie lifted from a browser. Understanding that split matters more in 2027 than picking a “winner,” because the pressure on both protocols is coming from directions the specs never controlled.
What SAML Actually Does
SAML 2.0 became an OASIS Standard in March 2005, which makes it old enough to vote and still running a large share of enterprise logins. It works through signed XML assertions: an identity provider (IdP) tells a service provider (SP) “this person authenticated, and here are their attributes.” The full mechanics live in the SAML 2.0 core specification if you want the normative detail.
The practical shape is a browser redirect dance. You hit an app, get bounced to your company IdP, log in there, and get bounced back with a signed assertion. The app never sees your password. Attributes like group membership or department ride along inside the assertion, which is why SAML became the backbone of corporate single sign-on.
Two things SAML does not do. It does not carry delegated API authorization, and it does not define how a mobile app should talk to an identity provider without a browser. Those gaps are exactly where OIDC moved in.
What OIDC Actually Does
OpenID Connect 1.0 was finalized in February 2014 as an identity layer on top of OAuth 2.0. Instead of XML assertions, it issues a signed ID token in JSON Web Token format, plus an access token for calling APIs. The OpenID Connect Core specification defines the whole flow.
That access token is the structural difference. SAML answers “who is this person?” OIDC answers that question and then hands the app a key to call other services on the user’s behalf. For mobile apps, single-page apps, and anything API-first, that combination is why OIDC became the default for new builds.
Here is the comparison in plain terms:
| Dimension | SAML 2.0 | OIDC |
|---|---|---|
| Standardized | 2005 (OASIS) | 2014 (OpenID Foundation) |
| Token format | Signed XML assertion | Signed JSON Web Token |
| Primary transport | Browser redirects (POST/Redirect bindings) | REST/JSON over HTTPS, browser or native |
| API authorization | Not defined by the spec | Built in via OAuth 2.0 access tokens |
| Mobile and SPA support | Awkward, browser-centric | Native fit |
| Typical buyer | Enterprise SaaS, legacy apps | New apps, consumer and API products |
| Trust anchor | Signed metadata | Discovery document plus JWKS |
Neither column is a security score. A badly configured OIDC deployment is worse than a well-run SAML one, and vice versa.
The Trust Anchor Both Protocols Share
Strip away the syntax and both protocols rest on the same foundation: signing keys and metadata. SAML publishes signed metadata describing endpoints and certificates. OIDC publishes a discovery document and a JSON Web Key Set. If an attacker can swap a key or poison the metadata, the protocol’s elegance is irrelevant.
This is where real-world deployments fail most often, and it rarely makes headlines:
- Expired signing certificates. SAML certificates set to expire on a forgotten date take down logins at 2 a.m. Key rotation should be a scheduled, tested process, not a fire drill.
- Stale metadata caches. A service provider caching metadata for days will not notice an IdP’s key rotation until logins break.
- Overly broad trust. Adding a second IdP “temporarily” during a merger and never removing it leaves a permanent door.
Practical tip: put certificate expiry dates on the same calendar as domain renewals, with a 90-day warning. It sounds mundane. It prevents more outages than any protocol choice ever will.
Where the Limits Begin: The Endpoint Problem
Neither spec protects the device in front of the user. Phishing pages that proxy a real IdP, malware reading a session cookie, and stolen tokens replayed from another country all sit outside SAML and OIDC alike. The OAuth 2.0 Security Best Current Practice (RFC 9700, published January 2025) catalogs these attack classes for OAuth and OIDC deployments, and the list is a useful reality check for anyone who thinks protocol choice equals protection. (OpenID Connect)
The same logic applies to the broader attack surface around any login system. If you want a structured way to think about third-party and vendor risk sitting next to your identity stack, this explanation of where your supply chain risk actually lives is worth reading alongside the protocol specs.
What actually closes the endpoint gap is layered, and none of it is glamorous:
- Phishing-resistant authenticators. Passkeys and hardware security keys bind the credential to the real domain, so a proxy page gets nothing useful.
- Short token lifetimes with refresh rotation. A stolen access token should be worthless within minutes, not hours.
- Sender-constrained tokens. Binding tokens to a client certificate or device key makes replay far harder.
- Session monitoring. Impossible-travel alerts and device fingerprinting catch what cryptography cannot.
The uncomfortable truth: a company with SAML, passkeys, and tight session controls is safer than one with OIDC and passwords. The protocol is the frame, not the lock.
The 2027 Pressure Points Nobody Standardized For
So what changes by 2027? Not a protocol retirement. There is no standards-body roadmap that sunsets SAML, and claims that OIDC “replaces” it are commentary, not standards. The OASIS SAML 2.0 standard remains current, and no approved SAML 3.0 exists. The real 2027 story is three pressures squeezing both protocols at once.
Post-quantum signatures
Both SAML’s XML digital signatures and OIDC’s JWT signing profiles depend on algorithms that a future quantum computer could break. NIST finalized its first post-quantum signature standard, ML-DSA (FIPS 204), in August 2024, and the migration clock for long-lived identity infrastructure started then. Neither SAML nor the common OIDC profiles have standardized post-quantum signing algorithms yet. That means 2027 planning is really about inventory: which IdPs, which certificate authorities, and which downstream apps would need to change if signing algorithms shift. Organizations that catalog their signing dependencies now will migrate in months. Those that do not will migrate in years.
Browser cookie restrictions
Browser-based SSO has leaned on third-party cookies for years, and the phase-out timelines have slipped repeatedly. Any confident claim that cookies disappear on a specific 2027 date should be treated with suspicion. The practical move is to test your SSO flows with third-party cookies blocked today, because some fraction of your users already browse that way.
Regulatory baselines
NIST’s digital identity guidelines, SP 800-63-4, were finalized in 2025 and cover federation and assertion protection directly. Auditors increasingly ask for evidence that federation trust is documented and reviewed, rather than only evidence that it functions. If your SAML metadata or OIDC client registrations have never been audited, that gap will surface in a compliance review before any protocol migration does.
Picking Between Them Without Regret
The decision framework is simpler than most vendor decks suggest:
- Keep SAML for existing enterprise SaaS, anything with mature SAML integrations, and environments where the identity team already has deep operational experience.
- Choose OIDC for new applications, mobile and single-page front ends, API-first architectures, and consumer-facing products.
- Run both when mergers, acquisitions, or a long SaaS tail make standardization impractical. Both protocols can share one IdP, and most major identity providers support both.
Common mistakes worth naming: treating OIDC as automatically more secure because it is newer, assuming SAML cannot support modern apps, and skipping the metadata hygiene that both protocols demand. A related trap is tool sprawl around identity and access. Teams often bolt on overlapping security tools without checking what each one actually covers, the same pattern this comparison of data loss prevention tools and what they actually protect describes for a different layer of the stack. (Benefits canva alternatives where other tools actually win)
If you are evaluating adjacent security decisions while planning identity work, the same “what does it actually protect” question applies to your antivirus choice, and a clear-eyed look at which free antivirus software actually protects you in 2026 follows the same logic. (OpenID Connect overview)
What Good Looks Like in Practice
A realistic 2027-ready identity posture looks like this:
- One IdP as the source of truth, with SAML and OIDC both served from it.
- Passkeys or hardware keys for privileged and high-value accounts, with passwords as a fallback only.
- Documented key rotation schedules, metadata refresh intervals, and certificate expiry tracking.
- A written inventory of every signing algorithm and certificate in the federation chain, ready for post-quantum migration planning.
- Quarterly reviews of which service providers and clients are trusted, with removal of anything stale.
None of that is protocol-specific. All of it determines whether the protocol works.
Conclusion
OIDC and SAML protect the same core thing: the moment of authentication, and the assertion that follows it. OIDC adds delegated API access on top, which is why it fits modern apps. SAML remains a durable standard for enterprise federation, and nothing in the standards record says otherwise. The limits begin exactly where the specs end, at the device, the session, and the signing keys. The organizations that fare best through 2027 will not be the ones that picked the trendier protocol. They will be the ones that treated identity as an operational discipline and planned for algorithm migration before it became urgent.
FAQ
Is SAML being retired in 2027?
No. SAML 2.0 remains a current OASIS Standard, and there is no approved SAML 3.0 or standards-body plan to retire it. Claims about a 2027 cutoff are commentary, not standards. The real 2027 concern is post-quantum signing migration, which affects SAML and OIDC alike.
Is OIDC more secure than SAML?
Not inherently. Both rely on signed tokens and trusted metadata, and both leave the user’s device and session outside their protection. Security depends on authenticator strength, token lifetimes, key management, and monitoring. A well-run SAML deployment beats a sloppy OIDC one.
Can one identity provider support both SAML and OIDC?
Yes. Most major identity providers serve both protocols from a single user directory. That is why mixed environments are common after acquisitions or during gradual modernization. The operational cost is maintaining two sets of metadata, certificates, and trust reviews.
What is the biggest real-world failure point for both protocols?
Signing key and metadata management. Expired certificates, stale metadata caches, and forgotten trust relationships cause more login outages and security gaps than protocol weaknesses. Scheduling key rotation and tracking certificate expiry prevents most of it.
Do passkeys replace SAML or OIDC?
No. Passkeys change how the user proves identity to the identity provider. SAML and OIDC still handle how that proof travels to applications. Passkeys make the authentication step phishing-resistant, but federation still needs a protocol.
What should teams do first to prepare for 2027?
Inventory every signing certificate, algorithm, and trust relationship in the federation chain. Then test SSO with third-party cookies blocked and review metadata refresh settings. That groundwork supports post-quantum migration planning and compliance reviews without requiring a protocol change.
That groundwork also gives you leverage when vendors announce their own post-quantum timelines. Ask them which signature algorithms they support, how they will rotate keys during migration, and whether their metadata publication process can handle dual signing during the transition. Vendors without answers are telling you something useful. None of this requires abandoning either protocol, and it should not. The organizations that treat identity as infrastructure worth maintaining, rather than a checkbox to deploy once, will absorb whatever 2027 brings without a rushed migration or a 2 a.m. outage.
