One does authorization, the other does authentication. They overlap more than you'd think.
| OAuth 2.0 | SAML 2.0 | |
|---|---|---|
| Primary purpose | Authorization (delegated access) | Authentication (single sign-on) |
| Token format | JSON (JWT common) | XML assertions |
| Transport | HTTP redirects + REST APIs | HTTP redirects + POST bindings |
| Best for | APIs, mobile apps, SPAs | Enterprise SSO, web apps |
| Complexity | Simpler, more developer-friendly | Complex XML, signature validation |
| Mobile support | Native — designed for it | Awkward — XML in mobile is painful |
| Attack surface | Token theft, redirect URI manipulation | XML signature wrapping, assertion replay |
OAuth 2.0 is an authorization framework — it lets a user grant an application limited access to their resources without sharing credentials. The access token says what the app can do, not who the user is. OpenID Connect (OIDC) adds an identity layer on top for authentication. Most modern APIs and mobile apps use OAuth/OIDC.
SAML 2.0 is an authentication protocol designed for enterprise single sign-on. The Identity Provider (IdP) sends a signed XML assertion to the Service Provider (SP) confirming the user's identity. It's battle-tested in enterprise environments but the XML-heavy design makes implementation error-prone — XML signature wrapping attacks have hit major providers.
OAuth attacks focus on redirect URI manipulation, token leakage, and CSRF in the authorization flow. SAML attacks target XML parsing — signature wrapping, assertion injection, and XXE in SAML processors. Both require careful implementation; the spec alone doesn't guarantee security.
For new applications, especially APIs and mobile: OAuth 2.0 + OIDC. For enterprise SSO where SAML is already established: SAML. Many organizations run both — SAML for internal SSO and OAuth for API access.