OAuth vs SAML: delegated access is not single sign-on

OAuth and SAML are often compared as if they were competing login protocols. They were built for different jobs:

• OAuth 2.0 is an authorization framework. It lets a user grant an application limited access to resources (an API, a mailbox, a repository) without handing over a password.
• SAML 2.0 is a single sign-on protocol. It lets an identity provider send a signed statement about a user to an application, so the user does not sign in again.

OAuth is how an app gets a token; SAML is how an app gets an assertion about a person.

What each one actually does

The confusion starts because OAuth is frequently used as a login mechanism. That use is specified separately: OpenID Connect adds an identity layer on top of OAuth 2.0, with an ID token and a userinfo endpoint. A "sign in with Google" button is OIDC, not plain OAuth. See OAuth vs OIDC.

When SAML is the right answer

SAML is strongest where it has been for two decades: enterprise SSO for browser applications.

• A company buys a SaaS product and wants employees to sign in through its own identity provider.
• The application only needs a browser redirect and a signed assertion; no API delegation.
• The buyer's identity provider is Okta, Entra ID or another SAML-heavy product.
• Attributes such as groups and roles need to arrive with the login.

If a sales contract says "SAML SSO", that is what it means. Many enterprise procurement checklists still name SAML first.

When OAuth (with OIDC) is the right answer

OAuth is the right foundation when there is an API and a client that acts on the user's behalf:

• Mobile and single-page applications signing users in (OIDC with the authorization code flow and PKCE).
• Service-to-service calls with client credentials.
• Third-party integrations that need scoped access to a user's data.
• AI agents and MCP servers that call tools on behalf of a user with narrow scopes.

OIDC is also the better default for new applications, because it uses JSON and HTTPS instead of XML and signatures, and the same token machinery serves both login and API calls.

Security pitfalls, by protocol

SAML: the classic attack is XML signature wrapping, where an attacker moves the signed part and changes the assertion around it. The defense is a strict parser and validating the signature over the exact element you read. Replay protection, audience restriction and short validity windows matter too.

OAuth: the classic mistakes are leaking access tokens to the browser history or referrer, using the implicit flow for public clients, and skipping PKCE. Use the authorization code flow with PKCE, keep tokens in memory or a secure store, and validate the state parameter. Bearer tokens must travel over TLS.

Neither protocol protects a badly written client. Most real-world incidents come from implementation, not from the specification.

Can you use both?

Yes, and most companies do:

• The identity provider speaks SAML to legacy SaaS and OIDC to new applications.
• The same user account is behind both.
• Sessions are linked by the identity provider, not by the protocols.

That is why an identity provider needs to implement both, not choose one. Casdoor supports OIDC, SAML 2.0 and CAS from the same user store, so the same account can sign in to a SAML-only procurement requirement and an OIDC-native app.

Related reading: SAML vs OIDC, OAuth vs OIDC and authorization for AI agents.

Casdoor is open source and self-hostable, with a hosted option from $9 per month and no per-user fees.