Key takeaways
SAML, OAuth 2.0, and OpenID Connect (OIDC) are three protocols that handle communication between the applications people use and the directory that stores information about authorized users. Each serves a different purpose.
SAML handles authentication, i.e. proving a user's identity. It remains the most widely deployed protocol for enterprise single sign-on (SSO).
OAuth 2.0 handles authorization. This gives an application limited access to a user's resources without exposing the user's password.
OIDC adds an authentication layer on top of OAuth 2.0, so a single flow can verify who a user is and what they're allowed to do.
Most organizations use more than one protocol, and the choice of protocol depends on application requirements: SAML for legacy enterprise apps, OAuth for API access, OIDC for modern and mobile sign-in.
SAML vs. OAuth vs. OIDC at a glance
The table below compares SAML 2.0, OAuth 2.0, and OpenID Connect across six attributes. Use it as a quick reference when evaluating which protocol fits a given use case.
Feature | SAML 2.0 | OAuth 2.0 | OpenID Connect |
|---|---|---|---|
Primary purpose | Authentication (with authorization attributes) | Authorization (delegated access) | Authentication and authorization |
Token / assertion format | XML assertion (digitally signed) | Access token (opaque to the client) | ID token (JWT, JSON-formatted) |
Transport | HTTP Redirect / POST (browser-based) | HTTP / REST (API-friendly) | HTTP / REST (API-friendly) |
Common use case | Enterprise SSO across web apps | API authorization between services | Consumer and mobile sign-in |
Year standardized | 2005 | 2012 | 2014 |
Session management | Yes (via IdP session) | No (stateless tokens) | Yes (via session management spec) |
Think of it as | Enterprise SSO for web applications | Giving apps permission to act on your behalf | Proving who you are in modern and mobile apps |
The key takeaway: SAML authenticates users and dominates enterprise SSO. OAuth authorizes access to APIs and resources. OIDC adds authentication on top of OAuth for modern, mobile, and cloud-native applications. Many identity platforms support all three, which means the choice often depends on what your applications require, rather than which protocol is objectively superior.
How each protocol works
Each protocol follows a different sequence to move a user from "not yet verified" to "authenticated and authorized." The steps below describe what happens conceptually — not at the code level, but at the level an IT administrator would see when configuring an integration.
How does SAML authentication work?
SAML uses an XML-based exchange between the identity provider (IdP) and the application (called the "service provider" in SAML's terminology). The entire conversation happens through the user's browser, following these steps.
The user requests access to an application.
The application does not have a session for this user. It generates a SAML authentication request and redirects the user's browser to the identity provider.
The identity provider authenticates the user, typically by checking credentials against the company's user directory.
The identity provider builds a SAML assertion. This is an XML document containing the user's identity, attributes (like department and role), and a digital signature proving the assertion hasn't been tampered with.
The identity provider sends the assertion back to the application through the user's browser via an HTTP POST. The application validates the signature, reads the assertion, and grants access.
The user never enters credentials at the application itself. The identity provider handles authentication and sends the result using SAML, and the application trusts the signed assertion it receives.
How does OIDC add authentication to OAuth?
OIDC extends the OAuth 2.0 authorization code flow by adding one critical element: an ID token. This is what makes OIDC an authentication protocol, not just an authorization one.
When a user accesses an application, it redirects the user to the OpenID provider (which is also an OAuth authorization server), requesting the "openid" scope.
The user authenticates with the OpenID provider.
The provider issues an authorization code and redirects the user back to the app.
The application exchanges the code for two tokens: an access token (for resource access, same as OAuth) and an ID token (a JWT containing verified identity claims, such as the user's name, email, unique identifier, and when they authenticated).
The application validates the ID token's signature and reads the identity claims. The application now knows who the user is and can establish a session.
The ID token is the difference. OAuth alone can tell an application "this user approved access to their files." OIDC adds "and this user is Jane in the finance department, authenticated 30 seconds ago." That distinction matters when the application needs to personalize the experience, enforce role-based access, or maintain an audit trail.
When to use SAML vs. OAuth vs. OIDC
The right protocol depends on the application, the user population, and the architecture you're building on. Here are four common scenarios and the protocol each one calls for.
Enterprise workforce SSO across web and SaaS applications: Employees need to log in once and access dozens of internal and cloud applications — HR systems, finance platforms, and productivity suites. The applications are primarily browser-based. SAML is the standard here. Most enterprise identity providers and SaaS applications support SAML 2.0 integrations out of the box.
Third-party API integrations where a user grants limited access: A project management tool needs to read files from your cloud storage. A reporting dashboard needs to pull data from your CRM. The user approves a specific permission, and the application gets a token, not a password. OAuth 2.0 is designed for exactly this: scoped, delegated access between services.
Consumer-facing or mobile application sign-in: Your application needs to authenticate users on phones, tablets, or single-page web apps. OIDC is the fit. Its JSON-based tokens and REST APIs work natively with mobile SDKs and modern front-end frameworks. OIDC also supports the "Sign in with" flows (Google, Apple, Microsoft) that consumer applications rely on.
Modern enterprise environments that need SSO and API authorization: You're building a hybrid stack: some applications are traditional web apps, others are single-page applications, or microservices communicating through APIs. OIDC plus OAuth 2.0 together cover both authentication and authorization. Many organizations run more than one — SAML for enterprise web apps, OAuth for API-level access, and OIDC for modern and mobile sign-in. In practice, this often means combining single sign-on with federated identity management under a unified access strategy.
Can OAuth replace SAML? Not directly. OAuth handles authorization, not authentication. OIDC — which extends OAuth — can serve as an alternative to SAML for authentication use cases. But replacing SAML in an enterprise environment means migrating every application that currently relies on SAML assertions, and many legacy applications only support SAML. The practical answer for most organizations: an identity platform that manages both SAML and OIDC from a single console. For a deeper look at how these protocols relate, see SAML vs. SSO, then explore how Duo Single Sign-On puts both to work.
Security considerations for SAML and OAuth
Do you need to consider OAuth vs. SAML security parameters? No protocol is inherently more or less secure than another. Security depends on implementation. Each protocol has a different attack surface, and administrators should know where to focus during configuration and review.
How do SAML, OAuth, and OIDC validate tokens?
Each protocol uses a different format to package and verify identity or access data — SAML uses XML-based assertions, while OAuth and OIDC use tokens. SAML assertions are XML documents protected by digital signatures. The application validates the signature to confirm the assertion hasn't been tampered with.
OIDC ID tokens are JWTs, signed with a key the application can verify by retrieving the provider's public key.
OAuth access tokens work differently. The application can't read or validate them directly. It presents the token to the service holding the resource, and that service checks the token with the authorization server.
How do these protocols address transport security?
All three protocols require TLS (the encryption layer that makes HTTPS possible) to protect data in transit. SAML and OIDC add a second layer: the tokens themselves carry digital signatures that the application can verify independently. OAuth access tokens don't — they rely on TLS for transport security and server-side validation at the endpoint.
How do token lifetimes and refresh cycles work?
OAuth 2.0 and OIDC support refresh tokens, which let an application request a new access token without requiring the user to log in again. This is useful for long-running sessions or background processes. SAML assertions have a validity window set by the identity provider, typically minutes. Once the access permission expires, the user re-authenticates through the identity provider.
Short-lived tokens combined with refresh cycles allow systems to re-evaluate a user's access continuously. This checks periodically whether their device is still compliant, their location is expected, or their role has changed, rather than trusting a single login for the duration of a session.
What are common protocol misconfiguration risks?
Some mistakes when implementing these protocols expose identity systems to risk. For SAML, the most common configuration gaps involve signature validation and expiration. If the application doesn't confirm that it's reading only the signed portion of the document, additional content can be inserted that the application trusts, even though it was never verified by the identity provider. If the application doesn't enforce expiration timestamps, a valid assertion can be reused after it should have expired. To mitigate these risks, enforce strict schema validation and set short assertion validity windows. (For detailed SAML security guidance, see the OWASP SAML Security Cheat Sheet.)
For OAuth, the most common gaps involve redirect URIs and scope grants. If the authorization server accepts redirect URIs that aren't on a strict allowlist, an authorization code can be sent to an unintended destination. If scopes are granted more broadly than the application needs, a compromised token carries more access than it should. Maintain a strict redirect URI allowlist and grant the narrowest scope possible to mitigate these risks. (OAuth's known security considerations are documented in RFC 6749, Section 10.)
For OIDC, the most common security gap is omitting single-use verification codes (called nonces) and session identifiers (called state parameters) during implementation. These values ensure that every login response is fresh and tied to a specific request. These parameters prevent token replay and cross-site request forgery, but they're optional in some implementations and easy to skip. Mitigation: always enforce nonce and state validation, even when the library doesn't require it.
