How OIDC Works

If OAuth 2.0 is the legal framework that lets you hand your house keys to a house-sitter, OpenID Connect (OIDC) is the standardized ID Badge the house-sitter wears so you know exactly who they are. Before OIDC, every API implemented "User Profile Fetching" radically differently. OIDC sits explicitly on top of OAuth 2.0 to provide a perfectly standardized, cryptographically verifiable way to authenticate identity.

---

Part 1: The Magic "openid" Scope

OIDC is entirely invisible unless requested. A client application kicks off the standard OAuth 2.0 flow but adds exactly one magic word to the requested scope string: openid.

For example: scope=openid profile email.

This single keyword triggers the Authorization Server (e.g., Google, Auth0, Okta) to switch gears. It still asks the user for permission, and it still issues a standard Access Token for API calls. But because of the openid scope, it mints a brand new, highly-specialized artifact: The ID Token.

Part 2: The Anatomy of an ID Token (JWT)

The ID Token is always a JSON Web Token (JWT). Unlike an opaque Access Token (which is often just a random string meant only for the Resource API to read), the ID Token is explicitly meant for the Client Application to read and verify.

When decoded (Base64), the payload contains standardized OIDC Claims:

• sub (Subject): The globally unique identifier for the user (e.g., 10552431...). This MUST never change.
• iss (Issuer): The URL of the Auth Server that minted this token (e.g., https://accounts.google.com).
• aud (Audience): The Client ID of the application this token was minted for. This prevents Token Substitution attacks.
• exp (Expiration): Unix timestamp when this ID Token expires.
• name & email: Profile data if requested in the scope.

Part 3: Cryptographic Verification (JWKS)

Because the ID Token is received from the front-channel (in Implicit Flow) or back-channel, the App MUST verify nobody tampered with the JSON.

The Auth Server hashes the JWT header and payload and signs the hash using its private RSA Key (creating the JWT signature).

The Client App reads the iss claim (Issuer URL), appends /.well-known/openid-configuration to find the Discovery Document, and fetches the JWKS (JSON Web Key Set). The JWKS contains the public RSA keys. The Client App mathematically verifies the signature using the downloaded public key. If it matches, the App has 100% mathematical certainty that the Auth Server minted this token and that the user data (like their email) is authentic.

Part 4: The /userinfo Endpoint

JWTs should be kept very small (to fit in HTTP Headers or secure cookies). Putting a user's entire address, manager chain, and phone number array into the ID Token would bloat the token beyond functional limits.

To solve this, OIDC defines a standardized /userinfo REST endpoint.

The Client App takes the standard opaque Access Token (received alongside the ID Token) and sends an HTTP GET request to the Auth Server's /userinfo endpoint. The Auth Server responds with a massive, unbloated JSON document containing every profile attribute the user authorized, allowing the initial ID Token to remain perfectly lightweight.