This article is written by the team that builds Casdoor, so we are not neutral, and we say where we think Casdoor fits and where it doesn't. Facts about other products come from their own websites as of November 1, 2026 (listed under Sources) and may have changed. Spotted something out of date? Tell us.
OAuth, SAML and OIDC get compared as if they were three brands of the same product. They solve different problems:
- OAuth 2.0: delegated access to APIs.
- OpenID Connect (OIDC): user login, built on OAuth 2.0.
- SAML 2.0: enterprise browser single sign-on.
Most companies end up using at least two of them. This article is the decision guide; each protocol has a deeper explainer linked below.
The one-line answers
| Question | Protocol |
|---|---|
| "Let this app read my calendar, but not my email" | OAuth 2.0 |
| "Sign this user in to my web or mobile app" | OpenID Connect |
| "Our enterprise customer wants SSO with their IdP" | SAML 2.0 (and often OIDC too) |
| "A service needs to call another service" | OAuth 2.0 client credentials |
| "A CLI needs to sign in a user" | OIDC device flow (OAuth grant) |
Side by side
| OAuth 2.0 | OIDC | SAML 2.0 | |
|---|---|---|---|
| Purpose | Authorization for APIs | Authentication for users | Browser SSO |
| Format | JSON / form posts | JWT | XML |
| Token / artifact | Access token | ID token (+ access token) | Signed assertion |
| Standard body | IETF | OpenID Foundation | OASIS |
| Typical client | API clients, services, agents | Web, mobile, SPA | Enterprise SaaS |
| User info | None defined | Userinfo endpoint, claims | Attribute statements |
| Provisioning | No | No | No |
None of the three provisions accounts. That is SCIM. See SCIM vs SAML.
When OAuth is the answer
Use OAuth when a client needs to act on behalf of a user against an API, or as itself:
- Third-party integrations with scopes.
- Mobile and SPA access to your own APIs.
- Service-to-service calls with client credentials.
- AI agents and MCP servers accessing tools with narrow scopes.
OAuth is not a login protocol. If you find yourself using an access token to decide "who is this user", you want OIDC. See what OAuth 2.0 is and OAuth grant types.
When OIDC is the answer
OIDC is the default for new user-facing applications:
- Web apps, SPAs, mobile apps.
- Anything that needs an ID token and standard user claims.
- Providers that support discovery, so configuration is one issuer URL.
It reuses OAuth's flows, so one identity provider can issue both access tokens for your APIs and ID tokens for your apps. See what OpenID Connect is and ID token vs access token.
When SAML is the answer
SAML is the answer when the other side requires it:
- An enterprise customer's identity provider is SAML-only (common with older Okta, ADFS and Ping deployments).
- A SaaS procurement checklist says "SAML 2.0".
- You need attribute-rich assertions for an existing enterprise app.
SAML is not obsolete — it is the language of enterprise procurement — but it is not where new application development should start. See what SAML is.
What a typical stack looks like
- An identity provider that speaks SAML, OIDC and OAuth.
- SAML connections for enterprise customers and legacy applications.
- OIDC for your own web and mobile apps.
- OAuth access tokens for APIs and machine-to-machine calls.
- SCIM for provisioning, separately.
That is the configuration Casdoor is built for: one user store, SAML for the applications that require it, OIDC for everything new, OAuth tokens for APIs.
A decision checklist
- Is there a user signing in? If yes, OIDC (or SAML if the customer requires it).
- Is there an API being called on a user's behalf? OAuth.
- Is another company's IdP involved? Ask which protocols it supports; usually both SAML and OIDC.
- Do accounts need to be created and removed outside logins? SCIM.
- Can one identity provider cover all of the above? Prefer that over stitching three products together.
Related reading: OAuth vs OIDC, OAuth vs SAML and SAML vs OIDC.
Sources
- RFC 6749: The OAuth 2.0 Authorization Framework
- OpenID Connect Core 1.0
- OASIS: SAML 2.0 technical overview
Product names are trademarks of their respective owners.