OAuth 2.0 vs OpenID Connect Explained for the Security+ Exam

OAuth 2.0 and OpenID Connect are constantly confused, and the distinction is the single most testable thing about them.

OAuth 2.0 is authorisation. OpenID Connect is authentication. OIDC is a thin identity layer built on top of OAuth 2.0, and it exists because people kept misusing OAuth for login.

What OAuth 2.0 actually does

OAuth lets you grant an application limited access to a resource you own on another service, without giving it your password.

The canonical example: a photo printing site wants your photos from a cloud storage service. Instead of handing over your storage password, you are redirected to the storage provider, you approve "this site may read your photos", and the site receives a token scoped to exactly that.

Key properties: the application never sees your credentials, access is scoped to specific permissions, and you can revoke it without changing your password.

The four roles the exam uses: the resource owner (you), the client (the application requesting access), the authorisation server (issues tokens), and the resource server (holds the data).

Why OAuth alone is wrong for login

An OAuth access token says the bearer is permitted to do something. It says nothing verifiable about who the user is.

Applications used to call an API with the token, get back a user profile, and treat that as proof of identity. The flaw is that a token issued to a different application for a different purpose could be replayed — the application had no way to confirm the token was issued for it, and this produced real vulnerabilities.

OIDC fixes it with a purpose-built identity token.

What OpenID Connect adds

The ID token. A signed JSON Web Token asserting the user's identity. Because it is signed by the identity provider and contains an audience claim naming the intended recipient, the application can verify both that it is genuine and that it was issued for this application.

Claims to recognise: iss the issuer, sub the unique subject identifier, aud the audience, exp expiry, iat issued-at, and nonce which binds the token to the original request and prevents replay.

The UserInfo endpoint for additional profile attributes.

Standard scopes — openid, profile, email — so behaviour is consistent across providers.

Discovery, allowing a client to configure itself from the provider's published metadata.

So the pairing is: ID token says who you are; access token says what you may do. That sentence answers most exam questions on this topic.

Flows worth recognising

Authorisation code flow is the standard and the secure choice. The client receives a short-lived code via the browser redirect, then exchanges it for tokens over a direct back-channel call. Tokens never travel through the browser.

Authorisation code with PKCE adds a cryptographic challenge so an intercepted code cannot be exchanged by anyone else. Originally for mobile apps, now recommended for all clients including web applications.

Implicit flow returned tokens directly in the browser redirect. It is deprecated because tokens ended up in browser history, referrer headers and logs.

Client credentials flow is machine-to-machine with no user involved.

If asked which flow to use, the answer is authorisation code with PKCE.

Compared with SAML

	SAML 2.0	OIDC
Format	XML assertions	JSON Web Tokens
Transport	HTTP POST / redirect binding	REST over HTTPS
Best suited to	Enterprise web SSO	Mobile, SPAs, APIs
Age	Mature, widely deployed	Newer, lighter weight

Both do federated authentication. SAML remains entrenched in enterprise applications; OIDC dominates anything mobile or API-driven because JSON and REST suit those clients better than XML.

Security considerations

Validate the ID token properly — signature, issuer, audience and expiry. Accepting a token without checking the audience is the classic implementation flaw. Use exact redirect URI matching, since loose matching enables token theft. Use the state parameter against CSRF and nonce against replay. Keep access tokens short-lived and treat refresh tokens as sensitive. And request the narrowest scopes that work — over-broad consent is how an application ends up with far more access than it needs.

What to remember

OAuth 2.0 authorises, OIDC authenticates, and OIDC is built on OAuth. The ID token is a signed JWT identifying the user; the access token grants API access. Use the authorisation code flow with PKCE; implicit flow is deprecated. Always validate the audience claim. SAML uses XML for enterprise SSO, OIDC uses JSON for modern and mobile clients.

Related reading: Federation: SAML, OAuth and OIDC · Kerberos · Authentication factors