How do SAML 2.0 and OAuth 2.0 / OpenID Connect compare, and how can they be combined?
OIDC is JSON- and token-based and much more flexible for mobile and browser-only (JavaScript) applications; SAML is simpler in scope, well established and long proven in federations. A common pattern uses SAML for web SSO in the federation and OAuth 2.0/OIDC for non-web and mobile clients.
| SAML 2.0 | OAuth 2.0 / OpenID Connect | |
|---|---|---|
| Data format | XML assertions, XML Signature | JSON, JWT (ID token, access token) |
| Main purpose | Authentication and attributes for web SSO | Delegated API authorisation (OAuth), authentication on top (OIDC) |
| Clients | Browser-based web applications | Web, native mobile, single-page apps, APIs |
| Maturity | Since 2005, very widespread in enterprises, universities and e-government | Since 2014 (OIDC), dominant for consumer logins and modern apps |
| Typical risks | XML parsing and signature wrapping, bearer assertion theft | Misconfigured redirects and flows, token leakage, phishing of consent screens |
On mobile and single-page apps: OIDC clients can run entirely in the browser in JavaScript. Historically this used the implicit flow, but current OAuth security guidance (RFC 9700, 2025) says clients should not use the implicit grant; browser apps now use the authorisation code flow with PKCE.
Combining the best of both: authenticate in the federation via SAML (web SSO via SAML), serve non-web and mobile clients via OAuth 2.0/OIDC, and let a broker issue one kind of token after a login with the other.
Go deeper:
OpenID Foundation: How OpenID Connect Works — the OIDC side of the comparison from its standards body.- RFC 9700, OAuth 2.0 Security Best Current Practice: Implicit Grant — why the implicit flow should no longer be used.
- Switch edu-ID: SAML vs OIDC — how a federation that runs both protocols on one IdP advises services to choose.