SAML, OpenID Connect, OAuth 2.0: What Are the Differences?
SAML, OpenID Connect and OAuth 2.0 come up in every single sign-on (SSO) project. These three protocols are often confused, yet they do not meet the same need. Understanding SAML vs OpenID Connect, and where OAuth 2.0 fits in, helps you avoid costly architecture choices and security flaws.
Authentication or authorisation: the starting point
Authentication answers the question “who are you?”. Authorisation answers “what are you allowed to do?”.
SAML and OpenID Connect authenticate a user and pass their identity to an application. OAuth 2.0, on the other hand, authorises an application to access resources on the user’s behalf. On its own, it says nothing about who that user is.
SAML 2.0: the long-standing enterprise SSO standard
Published by OASIS in 2005, SAML 2.0 carries identity in the form of signed XML assertions. The identity provider (IdP), for example ADFS or Microsoft Entra ID, authenticates the user. It then sends the assertion to the service provider (SP), meaning the application, through the browser.
SAML is mature and supported by virtually every enterprise SaaS application. Its XML format, however, is heavy, complex to secure and poorly suited to mobile applications and APIs.
OAuth 2.0: delegating access, not proving identity
OAuth 2.0, standardised by the IETF in 2012, lets an application obtain an access token limited to certain rights, called scopes. Example: a scheduling app reads your calendar without ever knowing your password.
It is now the de facto standard for securing access to APIs. The classic mistake is to use it alone to “log in” a user: an access token proves an access right, not an identity.
OpenID Connect: identity on top of OAuth 2.0
OpenID Connect, published in 2014 by the OpenID Foundation, adds an identity layer to OAuth 2.0. In addition to the access token, the application receives an ID token. It contains the user’s identifier, the issuer, and the time and method of authentication.
Based on JSON and simple web exchanges, OpenID Connect suits modern web applications, mobile apps and APIs. A standard discovery endpoint also lets the application configure itself automatically.
The comparison in one table
| Criterion | SAML 2.0 | OAuth 2.0 | OpenID Connect |
|---|---|---|---|
| Role | Authentication and SSO | Delegated authorisation | Authentication and SSO |
| Year | 2005 | 2012 | 2014 |
| Body | OASIS | IETF | OpenID Foundation |
| Format | Signed XML assertions | Access token, often in JWT format | JSON, JWT ID token |
| Typical use | SSO to enterprise and SaaS applications | An application’s access to an API | SSO for modern web and mobile applications |
| Strength | Widely used in enterprises | The standard for APIs | Simple and mobile-friendly |
| Limitation | Complex XML, poorly suited to mobile | Does not convey identity | Less common in legacy applications |
Which one should you choose?
- SaaS or enterprise application that only offers SAML: SAML, quite simply.
- New web, mobile or single-page application: OpenID Connect.
- Giving an application access to an API: OAuth 2.0, combined with OpenID Connect if the application also needs to know the user.
In practice, you do not have to pick a single protocol. Leading identity providers (Microsoft Entra ID, Okta, Keycloak, ADFS) handle SAML and OpenID Connect side by side, application by application.
Mistakes to avoid
- Using an OAuth access token as proof of identity.
- Failing to check the signature, issuer, audience and expiry date of tokens and assertions.
- Keeping outdated OAuth flows such as the implicit flow. Use the authorization code flow with PKCE instead.
- Forgetting that SAML signing certificates expire. An expired certificate on the IdP instantly cuts off access to every federated application.
Master identity federation
Our 4-day IAM training covers strong authentication, PKI, federation with SAML, OpenID Connect and ADFS, and cloud IAM with Azure and AWS, with 18 workshops and demos.
