SAML, OAuth 2.0 and OpenID Connect: which one you actually needSAML, OAuth 2.0 and OpenID Connect: which one you actually need

Almost every identity integration that goes badly went badly at the first decision. Someone chose the protocol they had used before rather than the one that matched the problem, and every subsequent difficulty was a consequence of that choice being slightly wrong in a way that only became visible under load, or under audit, or when the second identity provider arrived.

The three protocols in question are not competitors in the way procurement documents often imply. Two of them answer the same question in different eras and different formats. The third answers a genuinely different question and is routinely misused to answer the first.

What each one actually answers

OAuth 2.0 is an authorisation framework. It answers: what is this application permitted to do on behalf of this resource owner, and for how long? It issues access tokens scoped to permissions. It deliberately says nothing standard about who the user is. An access token is a permission slip, not an identity document, and treating it as one is the root of a whole family of security bugs.

OpenID Connect is a thin identity layer on top of OAuth 2.0. It adds an ID token (a signed JWT with standard claims about the authenticated user), plus a discovery document and a userinfo endpoint. It answers: who is this user, verified by an issuer you trust? Because it rides on OAuth 2.0, you can get authentication and authorisation from one exchange, which is why it dominates anything built in the last decade.

SAML 2.0 answers the same question as OpenID Connect, but it predates it by roughly a decade and expresses the answer as a signed XML assertion passed through the browser. It was designed for enterprise web single sign-on and it is extremely good at that specific job. It is also verbose, XML-signature-dependent, and awkward outside a browser context.

Choosing, in practice

The decision is usually made for you by the identity provider on the other side of the integration, and that is a legitimate reason to choose. When it is genuinely open, these are the deciding factors:

• Choose OpenID Connect for new work, for anything involving mobile or native applications, for machine-to-machine flows, and for anything where you also need authorisation scopes. It is the default and should be justified against rather than justified for.
• Choose SAML 2.0 when the enterprise identity provider you must integrate with supports it and nothing newer, when a procurement process explicitly requires it, or when you are joining an existing federation that speaks it. This is common in education, healthcare and public-sector estates, and it is not a legacy embarrassment; it is what the counterparty runs.
• Choose plain OAuth 2.0 only when you genuinely need delegated authorisation without authentication, such as a background service acting on a resource with a client-credentials grant, for example. If you find yourself deriving a user's identity from an opaque access token, you needed OIDC.

The four mistakes that cost the most

Using an access token as proof of identity

An OAuth access token is issued to a client for a resource. It is not audience-restricted to your application unless you made it so, and it is not required to say anything truthful about the end user. Applications that decode an access token and trust the subject claim can often be fed a token obtained for a different client entirely. The ID token exists precisely to be the identity artefact, with an audience claim you are required to validate.

Validating the signature and stopping there

A valid signature proves the token was issued by the key you trust. It proves nothing about whether the token was meant for you, whether it has expired, or whether it is being replayed. Issuer, audience, expiry and nonce all have to be checked, and on SAML the assertion's conditions (NotBefore, NotOnOrAfter, AudienceRestriction) plus replay protection on the assertion ID are equally non-optional.

Designing for exactly one identity provider

The first integration is with one provider. The second client wants their own tenant, the third is on a different protocol entirely. Systems that hard-code a provider's quirks into the authentication path end up with a parallel implementation per customer. Isolating identity behind an internal representation of an authenticated principal (issuer, subject, verified email, roles) costs very little at the start and saves a rewrite later.

Confusing authentication with authorisation

The identity provider tells you who someone is, and sometimes what groups they belong to. It does not know what they are allowed to do in your domain. Applications that map identity-provider group names directly onto permissions become undeployable the moment a client's directory is structured differently. Map external groups to internal roles at a boundary you control, and enforce authorisation on the server for every request rather than in the interface that renders the buttons.

What actually breaks in production

Protocol choice is the design risk. Operational failures are more mundane and more frequent: signing certificates expiring with no monitoring on the expiry date; clock skew between your servers and the identity provider rejecting otherwise valid assertions; SAML metadata updated by the counterparty without notice; token lifetimes short enough that a slow form submission lands after expiry. Each of these is preventable with a calendar entry and a health check, and each of them takes a production system down at least once for teams who did not add them.

Codentures designs and implements identity integration with Entra ID, Okta, SAML 2.0, OAuth 2.0 and OpenID Connect, and works alongside specialist firms where formal penetration testing is required.