SAML, OAuth, or OIDC: How to choose the right protocol
Choosing the right authentication protocol depends on your applications, your user types, and the protocols supported by your identity provider. This article considers these three main factors, and others, explaining how modern organizations deploy protocols, their best use cases, and common security risks introduced during configuration.
Key takeaways
Most organizations use more than one protocol. Match each protocol to the right use case and manage them through a single identity platform, not to consolidate onto one standard.
SAML remains widely deployed for enterprise single sign-on, with a market projected to grow through 2033. Use it for legacy applications and deployments that do not neatly communicate with newer protocols like OIDC.
OIDC and OAuth 2.0 are built for modern and mobile applications. OIDC verifies who the user is. OAuth 2.0 governs what a third-party application can do with their account. If your stack is moving toward cloud-native architectures, these are the protocols that fit.
No protocol is inherently more secure than another. Each has specific implementation risks. These include XML signature validation for SAML, token lifetime management for OIDC and OAuth, and scope creep for OAuth. Security depends on configuration, not which standard you chose.
Is SAML really dead?
Not yet. Claims that "SAML is dead" surface in identity discussions every year or two, as newer standards emerge. Security Assertion Markup Language (SAML) 2.0 was standardized in 2005, which makes it old by software standards. However, asking whether SAML is outdated is different from asking whether it's obsolete. The SAML authentication market was valued at roughly $1.2 billion in 2024 and is projected to grow at a 15.3% CAGR through 2033. That is not the trajectory of a dying standard.
SAML remains the backbone of enterprise single sign-on, with large organizations running SAML integrations across applications like Salesforce, Workday, AWS Console, and Microsoft 365. When an employee at one company needs to access a partner's application without a separate login, SAML is typically what makes that work. The "dead" narrative reflects the rise of OpenID Connect (OIDC) and OAuth 2.0 for newer use cases, including mobile apps, single-page applications, and API-first architectures. SAML’s XML-based approach doesn’t naturally fit these cases.
The question is not whether SAML is dead. It’s which protocol fits your specific needs. For a detailed technical comparison of all three protocols, see our article, SAML vs. OAuth vs. OIDC explained.
What three factors should drive your protocol decision?
Choosing an authentication protocol is a practical decision influenced by three factors: your applications, your users, and your identity infrastructure.
What does your application architecture look like?
SAML was designed for traditional web applications that run on a server and communicate through browser redirects. It exchanges XML assertions between the identity provider, which stores user information, and the service provider—the app itself.
This model maps cleanly to the way enterprise web applications have worked for two decades. If most of your applications are server-rendered enterprise tools with established SAML integrations, then SAML may be the only protocol they support, or at least the one they were designed to run on. Providing they are properly configured, there’s nothing wrong with keeping those integrations in place.
OIDC and Open Authorization (OAuth) 2.0 were designed for a different architecture. Single-page applications, mobile apps, and API-first services don't communicate through browser redirects and XML. They use Representational State Transfer (REST) endpoints and JSON, which are lighter, faster, and native to the way modern applications are built.
OIDC handles authentication in this context: it verifies who the user is and returns that identity as a JSON Web Token. OAuth 2.0 handles authorization: it governs what a third-party application can do with a user’s account, without ever sharing the user's password. If your application portfolio is moving toward cloud-native architectures, these are the protocols that fit.
Who are your users?
Workforce identity has historically run on SAML. Employees log in to internal tools and SaaS applications through an enterprise identity provider, and most of those providers ship with SAML support built in. Most SaaS vendors accept SAML assertions for single sign-on (SSO). Learn more about the difference between SAML and SSO here. For enterprise workforce SSO, the choice between SAML and OAuth comes down to what is already in place. If your organization already has these integrations running, SAML is doing its job.
Customer identity tells a different story. Consumer-facing applications, partner portals, and mixed user populations lean toward OIDC because it supports social login flows ("Sign in with Google" for example), handles mobile authentication cleanly, and uses JSON Web Tokens (JWTs) that modern frontend frameworks can parse directly.
The OpenID Foundation reports that OpenID Connect is now used by billions of people across millions of applications. If your user base includes customers, partners, or contractors who authenticate outside your enterprise directory, OIDC is designed for these users.
What does your ecosystem already support?
Most modern cloud identity platforms support both SAML and OIDC. The deciding factor often comes down to what your applications accept. Some legacy applications only speak SAML. Some modern applications only speak OIDC. Understanding when to use SAML, OAuth, and OIDC [LINK TO: Learn article C30] at the protocol level helps inform which integrations require which protocol.
What are the security trade-offs between these protocols?
Is OAuth more secure than SAML? Is OIDC safer than either? No protocol is inherently more secure than another. The difference between a secure implementation and a vulnerable one comes down to configuration, not which standard you choose. That said, each protocol has characteristics that affect security in practice.
Token format and validation
SAML assertions are XML-signed and validated against the identity provider's certificate. The assertion is self-contained, so the service provider can verify it without calling back to the identity provider.
The risk: XML signature validation can be complex to correctly implement, and gaps in that logic could expose the system to signature wrapping attacks.
OAuth 2.0 access tokens are opaque to the client. The application passes them along without inspecting their contents. This limits exposure if client-side code is compromised.
The risk: The client has no way to detect a tampered or expired token on its own. It relies entirely on the authorization server.
OIDC uses JSON Web Tokens (JWTs) with standardized validation libraries available in most languages. Implementation is straightforward.
The risk: Developers who skip signature verification or fail to check the issuer and audience claims can undermine the entire validation chain.
Token lifetimes and session management
SAML assertions have short validity windows, typically measured in minutes. A stolen assertion expires quickly on its own.
The trade-off: short lifetimes mean more frequent re-authentication, which can create friction for users in long work sessions.
OAuth 2.0 supports refresh tokens that let applications request new access tokens without forcing the user to log in again. Sessions stay alive without re-exposing credentials.
The trade-off: refresh tokens can persist for days or weeks. A stolen refresh token stays useful until explicitly revoked, so teams need active token rotation and revocation built into their implementation.
OIDC inherits OAuth 2.0's refresh token model and adds session management capabilities through its session management specification.
The trade-off is the same: long-lived tokens require disciplined lifecycle management, or a compromised token becomes a persistent backdoor.
Common misconfigurations
SAML: Signature wrapping attacks and assertion replay are the primary risks. Both are preventable with proper validation, but the XML signature model has more surface area for implementation mistakes than JSON-based alternatives.
OAuth 2.0: Open redirect vulnerabilities and scope creep. Teams often grant applications broad permissions during development and never tighten them for production. Every scope should be as narrow as the application's function allows.
OIDC: Omitting the nonce and state parameters in authentication requests can allow token replay attacks. These parameters are easy to include and easy to forget, especially when developers copy example code that skips them.
All three protocols require TLS (Transport Layer Security) for transport. None is inherently safer than the others. The question is which security model your team is better equipped to implement and maintain correctly.
The protocol you choose matters less than how carefully you implement it. Most authentication vulnerabilities trace back to misconfiguration, not protocol design.
Why do most teams end up using more than one protocol?
In practice, most enterprises do not pick a single protocol; they use several. A 2025 analysis found that 72% of enterprises now run multi-protocol SSO environments. SAML is commonly deployed for legacy enterprise application SSO, while OIDC enters the picture for modern and mobile applications, and OAuth 2.0 for API authorization, with all managed through a single identity platform.
The goal is not to eliminate SAML or consolidate onto one protocol. Instead, adopt the right protocol for each use case and unify management. An organization might have 200 SAML integrations with established SaaS vendors and a growing set of OIDC integrations with newer cloud applications. Both can coexist, and both can be governed from the same identity provider. The risk is not in having multiple protocols. The risk is in managing them through separate, disconnected systems with potentially inconsistent policy enforcement and session revocation.
Identity platforms like Cisco Duo support both SAML 2.0 and OIDC through Duo Single Sign-On, which means organizations can manage hybrid protocol environments from one place. Duo also supports passwordless authentication built on OIDC and FIDO2/WebAuthn standards—so the same platform that handles legacy SAML integrations can also support the modern authentication protocols organizations are moving toward.
See how Duo handles SSO for SAML and OIDC apps.
Ready to simplify how your organization handles authentication across protocols? Try Duo for free.