OAuth 2.0 vs OpenID Connect: authorization vs authentication

OAuth 2.0 lets an application get limited access to a resource on a user's behalf. OpenID Connect (OIDC) is a thin identity layer on top of it that adds an ID token, a signed JWT describing who authenticated. Use OAuth to call APIs. Use OIDC when you need to know who the user is.

What OAuth 2.0 actually gives you

OAuth 2.0 is an authorization framework. A client asks an authorization server for an access token, and later presents that token to a resource server. The framework says nothing standard about how to describe the person who approved the request. The token is a key, and the resource server decides what the key opens.

The OpenID Connect Core specification puts it directly: OAuth 2.0 provides authorization but does not define how to convey authentication or identity information.

What OIDC adds

OIDC is built on OAuth 2.0. The client includes the openid scope in the request, and the server returns an ID token alongside the usual access token. The ID token is a JWT with a fixed set of required claims:

• iss: the issuer, an https URL
• sub: a stable identifier for the user, never reassigned
• aud: must include the client's own client_id
• exp and iat: expiry and issue time

OIDC also defines a nonce to tie the ID token to a specific login attempt, and a UserInfo endpoint where the client can fetch more profile data using the access token.

Without the openid scope the request is still valid OAuth, but it is not an OIDC request and the behaviour is unspecified.

Which one do you need

Ask what the application must learn.

• "Can this app read the user's calendar?" That is authorization. OAuth is enough.
• "Who just signed in, so I can create a session?" That is authentication. Use OIDC.
• "Both." Most web apps that sign users in and call APIs use one OIDC request that returns both tokens.

A common mistake

Teams sometimes use a bare OAuth access token as proof of login. The access token was issued to a client for a resource server. It was not issued to your app as evidence of identity, and its format may be opaque. Treating it as a login proof can let a token minted for one app sign someone into another.

The ID token is addressed to your client, which is why the aud check matters. A related habit is reading claims out of an access token in the browser. Access tokens are for the API. If your front end needs profile data, use the ID token or the UserInfo endpoint.

Practical checklist

1. Use OIDC for sign in, and request openid plus only the scopes you need.
2. Validate the ID token: issuer, audience, signature, expiry, nonce.
3. Send access tokens only to the API they were issued for.
4. Do not parse your identity from the access token.
5. Store sub together with iss as the user key, not the email address.

For the validation steps in detail, see OIDC ID token validation steps.

Quick check

Sources

• OpenID Connect Core 1.0
• RFC 6749, The OAuth 2.0 Authorization Framework

Last reviewed: 19 October 2026.