Security protocols comparison
OAuth vs SAML
Two identity and access standards that every engineer working on enterprise or API security needs to understand. They look similar — both enable single sign-on and delegated access — but they solve different problems with different technologies and different eras of the web in mind.
TL;DR
- OAuth 2.0 is an authorization framework. It lets a user grant a third-party app limited access to their resources. JSON tokens, REST-friendly, designed for modern web and mobile APIs.
- SAML is an authentication standard. It lets enterprises implement single sign-on across web applications using XML assertions issued by an Identity Provider.
- OpenID Connect (OIDC) adds authentication on top of OAuth 2.0 — this is what "Sign in with Google" actually uses. Many modern systems use OIDC for both authentication and authorization.
Side-by-side comparison
| Aspect | OAuth 2.0 / OIDC | SAML 2.0 |
|---|---|---|
| Primary purpose | Authorization (OAuth) + Authentication (OIDC) | Authentication + SSO federation |
| Token format | JWT (JSON Web Token) | XML assertion |
| Transport | REST / JSON over HTTPS | HTTP redirects with Base64-encoded XML |
| Typical use case | API authorization, "Login with Google/GitHub", mobile apps | Enterprise SSO (Okta, Azure AD, ADFS) |
| Mobile support | Excellent — designed for native and SPA flows | Poor — XML flows are browser-dependent |
| Complexity | Moderate — multiple grant types (code, client credentials, etc.) | High — XML signature, metadata exchange, browser redirects |
| Developer experience | Good — many libraries and hosted services | Harder — XML parsing, certificate management |
| Age / origin | OAuth 2.0 (2012), OIDC (2014) | SAML 2.0 (2005) |
When to use OAuth / OIDC
- API authorization. Service-to-service calls, mobile apps accessing backend APIs, and third-party integrations all use OAuth access tokens.
- Consumer-facing "Login with X" flows. Sign in with Google, GitHub, or Apple are all OIDC flows on top of OAuth 2.0.
- Modern SaaS products. Building a new product today, you almost certainly use an OIDC-compatible identity provider (Auth0, Cognito, Supabase) rather than implementing SAML.
- Mobile and single-page applications. The OAuth PKCE flow (Proof Key for Code Exchange) is designed for public clients that cannot store a client secret.
When to use SAML
- Enterprise SSO requirements. Large organisations' IT departments typically mandate SAML integration for any SaaS product employees use. Okta, Azure AD, and ADFS are SAML-first.
- Legacy systems. Enterprise portals, internal HR and ERP systems built in the 2000s–2010s use SAML and cannot easily migrate.
- Selling B2B SaaS to enterprises. If your customers are enterprises, you almost certainly need SAML SSO support — it is a common procurement requirement.
English phrases engineers use
OAuth / OIDC conversations
- "We're using OAuth for API authorization — clients present a bearer token."
- "The OAuth flow requires user consent before we get the access token."
- "We use the PKCE flow for the mobile app — no client secret."
- "The access token expires in an hour; the refresh token lasts 30 days."
- "The scope defines what the token can access — read:email, write:profile."
SAML conversations
- "We need to add SAML for enterprise SSO — the customer uses Okta."
- "The identity provider (IdP) issues the assertion after the user authenticates."
- "The SP-initiated flow redirects the user to the IdP login page."
- "We need to exchange metadata with their IdP to set up the trust."
- "The SAML assertion is signed with the IdP's X.509 certificate."
Key vocabulary
- IdP (Identity Provider) — the service that authenticates users and issues tokens or assertions (e.g., Okta, Azure AD, Google).
- SP (Service Provider) — the application that relies on the IdP to authenticate users (e.g., Salesforce, Jira, your app).
- Assertion (SAML) — a signed XML document issued by the IdP confirming the user's identity and attributes.
- Scope (OAuth) — a permission string declaring what resources the access token may access (e.g.,
openid profile email). - PKCE — Proof Key for Code Exchange; an OAuth extension for public clients (mobile, SPA) that cannot safely store a client secret.
- OpenID Connect (OIDC) — an identity layer on OAuth 2.0 that adds an ID token (JWT) proving who the user is.
- Bearer token — a token that grants access to whoever "bears" (presents) it; the resource server does not verify who obtained it.
Quick decision tree
- Authorising third-party apps to access your API → OAuth 2.0
- "Login with Google / GitHub" for consumers → OIDC (on top of OAuth 2.0)
- Enterprise customer requires SSO with Okta or Azure AD → SAML
- Mobile app authentication → OIDC + PKCE
- Service-to-service API access (no user) → OAuth 2.0 client credentials flow
- Both enterprise SSO and API access needed → SAML for SSO + OAuth for APIs
Frequently asked questions
Is OAuth for authentication or authorization?
OAuth 2.0 is an authorization framework — it grants third-party applications limited access to a resource on behalf of a user, without sharing credentials. It does not authenticate the user identity by itself. OpenID Connect (OIDC) is a thin identity layer built on top of OAuth 2.0 that adds authentication: it issues an ID token (a JWT) proving who the user is. When people say "log in with Google", they are using OIDC on top of OAuth 2.0.
What is SAML SSO?
SAML (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization data between an Identity Provider (IdP) and a Service Provider (SP). In enterprise SSO, the IdP (e.g., Okta, Azure AD) authenticates the user once. When the user visits a Service Provider (e.g., Salesforce, Jira), the SP redirects to the IdP which issues a signed XML assertion, proving identity without the user re-entering credentials.
Can you use OAuth and SAML together?
Yes. Many enterprise setups use SAML for authentication (IdP-to-SP SSO) and OAuth/OIDC for API authorization. Some IdPs (Okta, Azure AD) act as both a SAML IdP and an OAuth/OIDC provider. A common pattern: employees authenticate via SAML SSO into an enterprise portal, and OAuth tokens are then issued for accessing downstream microservices or third-party APIs.
What is the OAuth consent screen?
When an OAuth client requests access to a user's resources, the authorization server shows the user a consent screen listing the requested scopes (e.g., "This app wants to read your email"). The user approves or denies. This consent model is central to OAuth's delegation design — the user explicitly authorises the third-party app, and can revoke access later from the authorization server.
What is the difference between an access token and a refresh token in OAuth?
An access token is a short-lived credential (minutes to hours) that the client presents to resource servers to prove authorization. A refresh token is a long-lived credential stored securely, used only to obtain new access tokens from the authorization server without requiring the user to re-authenticate. The separation keeps access tokens short-lived (limiting damage if stolen) while maintaining a good user experience.
Why is SAML used in enterprise but not consumer apps?
SAML was designed in the early 2000s for browser-based enterprise SSO. Its XML assertions are verbose, its flows are complex, and it has poor support for mobile apps and REST APIs. OAuth 2.0 and OIDC emerged later, designed for the modern web and mobile — JSON tokens, REST-friendly flows, and a simpler developer experience. Enterprise IT systems built on SAML continue using it for compatibility; new consumer-facing apps default to OIDC.