OAuth with OpenID Connect

OAuth 2.0 was designed purely for delegated authorization: it lets a client obtain an access token so it can call an API on a user's behalf, but it says nothing about who the user actually is. OpenID Connect (OIDC) is a thin identity layer built on top of OAuth 2.0 that adds a standardized ID token, a UserInfo endpoint, and well-defined claims like sub, iss, aud, and exp so applications can perform authentication, not just authorization.

The ID token is a JSON Web Token (JWT) consisting of a header, payload, and signature, and its payload carries standardized claims: iss (the issuer URL of the identity provider), sub (a stable unique subject identifier for the user), aud (the client_id the token was issued for), exp and iat (expiry and issued-at timestamps), and optionally nonce and auth_time. Unlike an opaque access token, the ID token is meant to be parsed and read by the client itself, never sent to a resource server as a bearer credential.

To authenticate a user with OIDC, the client redirects to the authorization endpoint with scope=openid (plus optional profile and email scopes), response_type=code, a state value, and a nonce. After the user authenticates and consents, the client exchanges the returned code at the token endpoint for an access_token, an id_token, and often a refresh_token. Before trusting any claim inside the id_token, the client must validate its signature against the provider's JSON Web Key Set (JWKS), and confirm iss, aud, exp, and nonce all match expectations.

Every conformant OIDC provider publishes a discovery document at /.well-known/openid-configuration listing its authorization_endpoint, token_endpoint, jwks_uri, and userinfo_endpoint, which lets clients auto-configure themselves instead of hardcoding URLs. The UserInfo endpoint accepts the access_token (not the id_token) as a bearer credential and returns additional profile claims such as name, email, and picture, scoped to whatever the client requested via the openid, profile, and email scopes.