OpenID Connect

OpenID Connect, the essentials

OAuth 2.0 grants access to a resource. OpenID Connect adds identity: who the person signing in is.

OAuth 2.0 and OpenID Connect: the difference

OAuth 2.0 answers “is this application allowed to access this data?” It produces an access token. It says nothing about the person.

OpenID Connect (OIDC) is an identity layer on top of OAuth 2.0. It adds an identity token (ID token), a userinfo endpoint and standard scopes (openid, profile, email). If you request the openid scope you are doing OIDC; otherwise, plain OAuth.

The actors

• User (resource owner): the person.
• Client (RP, relying party): the application that wants to know the person or access an API.
• OIDC provider (OP, authorization server): Entra ID, Okta, Keycloak, Google… it authenticates and issues the tokens.
• API (resource server): receives the access token and validates it.

The three tokens

• ID token: a signed JWT that says who signed in (sub), issued by whom (iss), for whom (aud = your client_id), when (iat, exp) and echoes your nonce. It is meant for the application, never for the API.
• Access token: the key the application presents to an API. Opaque or JWT, short-lived. The application must not read it.
• Refresh token: lets you get a new access token without asking the person again. Long-lived, to be protected like a password.

The endpoints

/.well-known/openid-configuration	Discovery: a JSON document listing all the other endpoints and the provider’s capabilities. A serious client only needs the issuer address.
jwks_uri	The public keys used to verify the tokens’ signature (rotation possible).
authorization_endpoint	Where the browser sends the person to authenticate.
token_endpoint	Where the application exchanges a code (or other) for tokens, server to server.
userinfo_endpoint	The person’s information, with an access token.
introspection, revocation	Check whether a token is still active (RFC 7662); invalidate it (RFC 7009).
end_session_endpoint	Logout requested by the application (RP-initiated logout).
device_authorization_endpoint	Start a “device” flow (RFC 8628).

The checks of a serious client

On an ID token: signature (keys from jwks_uri), exact iss, aud contains its client_id, exp not passed, nonce identical to the one sent, at_hash/c_hash when present. On the response: identical state, and PKCE (code_verifier) with the code flow.