OAuth vs SAML: Which One Does SSO, Which One Does APIs

"OAuth or SAML?" is usually the wrong question, because SAML 2.0 federates a person's login into a browser application and OAuth 2.0 delegates API access to a client, and most organisations need both at once. The confusion is costly: teams try to stretch SAML assertions into API credentials, or treat an OAuth access token as proof of who signed in, and both shortcuts open real attack paths. This guide frames the comparison as SAML for workforce single sign-on versus OAuth for API, integration and non-human identity (NHI) access, then covers the bridges between them (the SAML 2.0 bearer assertion grant and token exchange), the threat model and failure modes of each, controls, and a worked scenario. It is for identity architects, application owners and platform teams. The SAML versus OpenID Connect choice for login is covered in the SAML vs OIDC Guide, and the OAuth versus OIDC distinction in OAuth 2.0 vs OIDC; this page does not repeat them.

Key takeaways

• SAML answers "who is this person, and can this application trust that?". It is a federation standard (OASIS, March 2005) built around signed assertions delivered through the browser to a service provider.
• OAuth answers "what may this client do at this API?". RFC 6749 issues access tokens to clients, including clients with no user at all, which is why every machine-to-machine and AI agent integration lands on OAuth.
• They meet at the token endpoint, not at the login page. RFC 7522 lets a client trade a SAML assertion for an OAuth access token, and RFC 8693 token exchange defines SAML 1.1 and 2.0 token types, so a SAML estate does not block API access.
• The two have different crown jewels. For SAML it is the IdP token-signing key (Golden SAML, ATT&CK T1606.002); for OAuth it is the population of long-lived refresh tokens and client secrets held by integrations (T1528).
• Login controls do not protect OAuth grants. Phishing-resistant MFA on the SAML login does nothing once an integration's refresh token is stolen, so OAuth clients need their own inventory, scoping and revocation.

The short answer

Use SAML 2.0 (or OIDC) to sign employees into browser applications, especially enterprise SaaS that already ships a SAML connector. Use OAuth 2.0 whenever software calls an API: a single-page app calling its back end, a SaaS-to-SaaS integration, a CI pipeline, a microservice, an MCP server or an AI agent acting for a user. When an application needs both (a user signs in, then the app calls APIs for them), let SAML or OIDC handle the login and have the application obtain an OAuth access token for the API, either through its own authorisation code flow or by exchanging the SAML assertion at the token endpoint.

The only genuine "versus" decision is for a new application that could use either for login. There the choice is SAML versus OIDC, not SAML versus OAuth, and OIDC is usually preferred for new web, mobile and API-first clients because it arrives with OAuth already in place.

Why the two are not alternatives

SAML 2.0: a federation assertion

SAML is a framework for transferring identity, authentication, attribute and authorisation information between parties with an established trust relationship. An identity provider (IdP) issues an <Assertion> containing up to three statement types: authentication (how and when the user signed in), attribute (who they are, group memberships) and authorisation decision. The service provider (SP) validates the signature, audience, recipient and validity window, then creates its own session. Messages travel over bindings (HTTP Redirect, HTTP POST, HTTP Artifact, SOAP) and the profiles that matter in practice are Web Browser SSO and Single Logout. SAML does define a non-browser profile, Enhanced Client or Proxy (ECP), which uses the reverse SOAP (PAOS) binding, but it targets enhanced clients and proxies rather than general API access.

OAuth 2.0: a delegated authorisation framework

OAuth defines four roles (resource owner, client, authorisation server, resource server) and grants for obtaining an access token: authorisation code, client credentials, refresh token and extension grants. The access token is meant for the resource server (the API); it says that this client was authorised for these scopes, not who the user is. The client credentials grant has no user at all, which makes OAuth the natural protocol for workloads, integrations and agents. Current security rules are in RFC 9700 (Best Current Practice, January 2025), which forbids the resource owner password credentials grant, discourages the implicit grant and requires PKCE for public clients.

The consequence

SAML's job ends when the SP has a trustworthy statement about a person. OAuth's job starts when a piece of software needs to call an API. The overlap is narrow, so the practical questions are which protocol each flow should use and how the two connect.

Side-by-side comparison

Bridging the two: assertion grants and token exchange

An organisation with a mature SAML estate can still give applications OAuth access tokens without asking users to sign in twice. Two standards do this.

• SAML 2.0 bearer assertion grant (RFC 7522, Standards Track, May 2015): the client posts grant_type=urn:ietf:params:oauth:grant-type:saml2-bearer with a single base64url-encoded assertion to the token endpoint. The authorisation server must check that the <Audience> identifies itself (the token endpoint URL may serve), that a bearer <SubjectConfirmation> is present with a Recipient matching the token endpoint where required, that NotOnOrAfter is set, and that the signature or MAC verifies. Failures return invalid_grant.
• SAML assertion as client authentication: the same RFC defines client_assertion_type=urn:ietf:params:oauth:client-assertion-type:saml2-bearer, where the assertion's subject must be the OAuth client_id. This is rare in new builds, where private_key_jwt or mTLS is the usual choice, but it appears in older enterprise integrations.
• Token exchange (RFC 8693, January 2020): a client presents a subject_token and optionally an actor_token to a security token service and receives a new token. Token type identifiers include urn:ietf:params:oauth:token-type:saml2 and saml1 alongside access, refresh, ID and JWT types, so an STS can turn an inbound SAML assertion into a narrowly scoped access token, and can record the acting party for delegation. See the OAuth Token Exchange and Delegation Guide.

Two cautions apply to both bridges. RFC 7522 makes replay protection optional, so an authorisation server that accepts assertion grants should track assertion IDs until expiry and keep assertion lifetimes short. And the authorisation server becomes a high-value relying party: whoever can mint an assertion it trusts can mint access tokens, so the trusted issuer list must be as tightly controlled as the IdP signing key itself.

Threat model: SAML for single sign-on

• Forged assertions from a stolen signing key: an attacker with administrative access to the IdP exports the token-signing certificate and mints assertions for any user, bypassing password and MFA (ATT&CK T1606.002). In the SolarWinds SUNBURST compromise this was paired with new credentials added to existing application service principals, which is the OAuth side of the same intrusion. See the Golden SAML and Federation Trust Abuse Defence Guide.
• XML signature wrapping: the SP validates a signature over one element while its code reads another. OWASP's guidance is to select elements by absolute XPath, use a static or X.509 key selector, ignore embedded KeyInfo and confirm the ds:Reference URI points at the element actually consumed.
• Missing audience, destination or recipient checks: an assertion issued for one SP is replayed at another. The SP must match <Audience> to its entity ID and Destination to its exact ACS URL.
• Unsolicited (IdP-initiated) responses: without an AuthnRequest there is no InResponseTo to check and no login CSRF protection; allow it only where a legacy app needs it and allowlist any URL in RelayState.
• Replay of captured assertions: mitigated by short validity windows, OneTimeUse, ID tracking and clock synchronisation.

Protocol detail and hardening steps are in the SAML Security Guide.

Threat model: OAuth for API and NHI access

• Theft of refresh tokens and client credentials: integrations hold long-lived grants that act without any user present (T1528), then replay them (T1550.001). In the Salesloft Drift breach, attackers used a chatbot integration's OAuth tokens to export CRM data from many tenants; no user was phished, so SSO and MFA were never in the path.
• Over-broad scopes and audiences: a token valid at many resource servers turns one leak into many. RFC 9700 section 2.3 says access tokens should be audience-restricted, with RFC 8707 resource and the RFC 9068 aud claim as mechanisms.
• Token passthrough and confused deputies: an intermediary (an API gateway, an MCP server, an agent tool) forwards the token it received to a downstream API. The MCP authorisation specification says a server must not pass through the token it received and must only accept tokens issued for itself.
• Weak flows: implicit grant, password grant, missing PKCE and redirect URI pattern matching, all addressed in RFC 9700. See the OAuth 2.0 Security Best Current Practice (RFC 9700) Guide.
• Illicit consent: users grant a malicious multi-tenant app delegated scopes. See the Consent Phishing and Illicit OAuth Grants Guide.

Where identity fits: agents and non-human identities

SAML assumes a subject that has authenticated, usually a person at a browser. Non-human identities do not fit that shape: a workload has no browser and no interactive login, and an AI agent acting for a user needs a credential scoped to a task, a resource and a time window. OAuth provides the pieces: client credentials for workloads, the authorisation code flow with PKCE for agents acting for users, token exchange to record the acting agent as actor_token, and audience binding through resource. The MCP authorisation specification (version 2025-06-18) builds on OAuth 2.1, requires servers to publish RFC 9728 protected resource metadata, requires clients to send the RFC 8707 resource parameter and to use PKCE, and does not reference SAML. The practical pattern is that SAML or OIDC signs the human in at the IdP, and everything the agent then does is an OAuth grant that can be scoped, logged and revoked on its own. See Machine-to-Machine OAuth (Client Credentials) Guide and API Keys vs OAuth for MCP Servers.

Decision criteria

Small organisations: usually one cloud IdP that speaks SAML, OIDC and OAuth; the decision is per app connector, and the main work is inventorying OAuth grants. Large organisations: often a separate on-premises federation service, an API gateway and several authorisation servers; the risks are signing-key sprawl and inconsistent token policy, so standardise on one STS for exchanges and one register of trusted issuers.

Worked scenario: an insurer's claims portal

A mid-sized insurer signs staff into its claims portal with SAML through its corporate IdP. The portal calls a document API and a payments API, and a new AI assistant summarises claim files. Originally the portal forwarded the SAML assertion to the document API as an HTTP header, and the payments API was called with a shared API key.

1. Keep SAML where it works: staff login stays on SAML, with signed assertions, exact Destination and Audience checks, short validity windows and a hardware-protected signing key with alerting on any certificate export.
2. Stop sending assertions to APIs: the portal now exchanges the user's SAML assertion at the authorisation server (RFC 8693, subject_token_type set to the saml2 URN) for an access token with audience set to the document API and a 10 minute lifetime. Assertion IDs are tracked to block replay.
3. Replace the shared API key: the portal back end uses client credentials with private_key_jwt for the payments API, scoped to payments.read and payments.initiate, sender-constrained with mTLS.
4. Treat the assistant as its own client: it receives tokens through exchange, with the user as subject and itself as actor, scoped to the documents of the open claim only. It cannot reuse the portal's tokens.
5. Result: SAML still controls who signs in; every API call now carries a token that names its audience, its client and, for the assistant, its actor, and each can be revoked without ending the user's session.

How to implement

1. Inventory flows, not apps: for each application list how users sign in (SAML, OIDC, LDAP, local) and every outbound API call with its credential type. The SAML side usually lives in the IdP's enterprise app list; the OAuth side is spread across authorisation servers, SaaS admin consoles and secrets stores. See the SaaS and OAuth App Governance Guide.
2. Harden SAML first: signed assertions, audience and destination checks, IdP-initiated SSO off where not needed, signing keys in an HSM, certificate rollover rehearsed.
3. Remove assertions from API paths: find any API that accepts a SAML assertion or session cookie directly and move it behind an authorisation server via RFC 7522 or RFC 8693.
4. Apply RFC 9700 to every OAuth client: authorisation code with PKCE, no implicit or password grant, exact redirect URIs, asymmetric client authentication, audience-restricted and short-lived tokens, refresh token rotation or sender constraint.
5. Pilot and test: run the exchange in parallel for one API, compare authorisation decisions in logs, then cut over. Keep the old path disabled but deployable for one release as rollback.
6. Close the loop on revocation: confirm that disabling a user at the IdP also revokes their refresh tokens and agent grants, and that deleting an integration revokes its tokens at the authorisation server.

Detection and measurement

• SAML: alert on signing certificate export or addition of new federation trusts, on sign-ins to SPs with no matching IdP authentication event (a Golden SAML indicator), and on assertions rejected for audience or signature errors.
• OAuth: alert on refresh token use from new networks or autonomous systems, token requests for new scopes by existing clients, new credentials added to existing clients, and bulk API exports by integration identities. See How to detect use of a stolen OAuth refresh token.

Common failure patterns

• Using a SAML assertion as an API credential: forwarding the assertion or the session it created to back-end APIs, where it is a bearer token with the wrong audience and no scopes.
• Treating SSO as the end of access control: integration tokens bypass the login entirely, as the Salesloft Drift incident showed; MFA strength at sign-in says nothing about a stolen refresh token.
• Accepting assertion grants without replay tracking: RFC 7522 leaves replay protection optional, and a captured assertion can be redeemed again until it expires.
• Federation keys without monitoring: signing certificates exported or new trusts added with no alert, which is the precondition for forged assertions.
• "Migrating SAML to OAuth" for login: rebuilding sign-in on bare OAuth rather than OIDC, which reintroduces the access-token-as-identity mistake. Use OIDC; see SAML to OIDC Migration.
• One shared client for many agents: every agent uses the same OAuth client and token, so logs cannot tell them apart and revocation hits all of them.

Framework mapping

Practitioner checklist

• Every application has one documented login protocol and one documented API credential type.
• No API accepts SAML assertions or browser session cookies directly.
• SAML SPs check signature, Audience, Destination, InResponseTo and validity window; IdP-initiated SSO is off unless required.
• IdP signing keys are HSM-protected, owned, monitored and on a rehearsed rollover plan.
• Assertion grants and token exchanges track assertion IDs and issue short-lived, audience-bound tokens.
• All OAuth clients follow RFC 9700: PKCE, exact redirect URIs, no implicit or password grant, asymmetric client authentication.
• Each integration and agent has its own OAuth client, owner, scopes and review date.
• User disablement at the IdP revokes that user's refresh tokens and delegated agent grants.

Standards and references

• OASIS: Security Assertion Markup Language (SAML) V2.0 Technical Overview
• IETF: RFC 7522 SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants
• IETF: RFC 8693 OAuth 2.0 Token Exchange
• IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
• NIST: SP 800-63C-4 Digital Identity Guidelines, Federation and Assertions
• Model Context Protocol: Authorization specification
• OWASP: SAML Security Cheat Sheet

Related NHI Mgmt Group resources: LDAP vs SAML vs OIDC, OAuth 2.0 vs OIDC, OAuth 2.0 and OpenID Connect Guide, Top 10 OAuth Security Risks.