OAuth 2.0 vs OpenID Connect

The two are constantly conflated, including in product documentation. The distinction is straightforward: OAuth 2.0 answers what a client may do; OpenID Connect answers who the user is.

Core purpose

• OAuth 2.0 is an authorization framework. It determines which resources a client may access on behalf of a user. It says nothing about the user’s identity.
• OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. It adds authentication: verifying who the user is and communicating that to the client.

Using OAuth 2.0 alone for authentication is the classic mistake. An access token proves the client was granted access to something; it does not prove who the user is, and it is not addressed to the client that receives it.

Tokens

• OAuth 2.0 issues access tokens and refresh tokens.
  • Access token — grants access to specific resources, for a specific scope.
  • Refresh token — obtains a new access token when the current one expires.
• OpenID Connect adds an ID token, in JWT format, alongside those.
  • ID token — carries claims about the user: subject identifier, name, email and whatever else the provider releases. It is addressed to the client and validated by it.

Scopes

• OAuth 2.0 scopes describe resource access — read:calendar, write:posts. They are defined by the resource server; there is no standard set.
• OpenID Connect defines standard identity scopes:
  • openid — required, and what makes a request an OIDC request rather than a plain OAuth one
  • profile — basic profile information
  • email — email address and verification status
  • address — postal address
  • phone — phone number and verification status

Endpoints

• OAuth 2.0 defines the authorization endpoint and the token endpoint.
• OpenID Connect adds:
  • UserInfo — returns claims about the authenticated user
  • End-session — handles logout
  • Discovery (/.well-known/openid-configuration) — publishes the provider’s configuration, including the JWKS URI used to verify token signatures

Discovery is the practical difference in day-to-day integration work: an OIDC client can be configured from one URL, whereas a plain OAuth 2.0 integration requires each endpoint to be supplied by hand.

User information

• OAuth 2.0 has no standardised way to obtain information about the user. Every provider invents its own endpoint and its own response shape.
• OpenID Connect standardises the claims, in the ID token and at the UserInfo endpoint, so the same client code works against different providers.

Typical uses

• OAuth 2.0 — API authorization, delegated access to a third-party service, machine-to-machine access with the client credentials grant.
• OpenID Connect — single sign-on, mobile and web application sign-in, enterprise identity federation.

On AWS

Amazon Cognito user pools are both: a user pool is an OIDC provider and an OAuth 2.0 authorization server. It issues an ID token (OIDC), an access token with scopes (OAuth 2.0) and a refresh token. The API Gateway JWT authorizer for HTTP APIs enforces scopes from the access token, which is why the access token is the right one to send to an API and the ID token is not.

IAM supports both directions of federation: an OIDC identity provider registered in an account backs sts:AssumeRoleWithWebIdentity, and a SAML provider backs sts:AssumeRoleWithSAML.

Complexity

OAuth 2.0 is more flexible and leaves more decisions to the implementer — which is why so many OAuth 2.0 integrations are subtly insecure. OpenID Connect constrains those decisions: token format, validation rules, claim names and discovery are all specified. Where authentication is the requirement, use OIDC and use a library rather than assembling the flow by hand.