OAuth, OIDC, and Token Purpose

Keep sign-in, access, and token format distinct

Login requires an identity layer

A product login needs a standardized way to verify a user’s identity and convey the authentication result to the client.

Authorization is a separate question: what may a client access?

OAuth standardizes access, not login

OAuth 2.0 (RFC 6749) is an authorization framework. A client obtains an access token to request access to a protected resource.

OAuth itself does not standardize user login to the client.

Authorization and authentication differ

Question Security function
Who authenticated? Authentication
What access was granted? Authorization
How is token data represented? Token format

Treating these as one decision can lead to tokens being used by the wrong component.

Assign each role

Match the protocol and token to its purpose

OIDC standardizes sign-in

OpenID Connect Core 1.0 adds an identity layer on top of OAuth 2.0.

It lets a client verify an end-user’s identity based on authentication by the OpenID Provider and receive identity claims.

Tokens have different recipients

Token Represents Intended recipient
ID token Authentication event and identity claims Client application
Access token Granted access, possibly for a user or client Resource server

An access token’s represented principal depends on the authorization context.

JWT describes a token format

A JWT (RFC 7519) carries claims in a defined format. That format alone does not establish the token’s purpose or intended recipient.

OIDC specifies JWTs for ID tokens. OAuth access tokens may use other formats.

OAuth leaves token format open

RFC 6749 describes an access token as a string and permits different formats.

The core specification does not mention JWT. RFC 9068 defines a separate profile for JWT-formatted OAuth access tokens.

Validate tokens at the right boundary

  • The client validates an ID token under OIDC rules.
  • The resource server validates access tokens under the applicable token profile.
  • Check issuer, audience, and other requirements where that profile specifies them.
  • Do not accept a token just because it is a JWT.

Choose by purpose and recipient

Key Takeaway: OAuth obtains access. OIDC standardizes sign-in. JWT describes format, not purpose.

Send each token only to its intended recipient, and validate it according to its role.

Primary specifications and guidance

Questions?

Which component should receive each token?

Explore further with Mezu →