OpenID Connect(OIDC)

Built on

OAuth 2.0 authorisation code flow

What turns it on

openid in the scope parameter

Identity proof

ID token: always a signed JWT

Claims to check

Signature, iss, aud, exp, nonce

Discovery document

/.well-known/openid-configuration

Stable user key

iss + sub (sub is unique per issuer)

Specification

OpenID Connect Core 1.0 (2014)

1. 1

   Register the client

   Register your app with the identity provider to get a client_id (and a secret for server-side apps), and allow-list the exact redirect_uri the provider may send users back to.

2. 2

   Send an authentication request

   Redirect to the authorization_endpoint with response_type=code, scope=openid email, a random state, a random nonce and a PKCE code_challenge.

3. 3

   Exchange the code

   On the callback, check state, then POST the code and the code_verifier to the token_endpoint. The response holds an id_token, an access_token and often a refresh_token.

4. 4

   Validate the ID token

   Verify the signature with a key from the provider's jwks_uri, then check that iss equals the issuer, aud contains your client_id, exp is in the future and nonce matches the value you stored.

5. 5

   Create your own session

   Map the stable iss + sub pair (not the email) to a user record, start your app's session, and keep the access token for calls to the provider's APIs or its UserInfo endpoint.

• Using the access token as proof of identity

  An access token is meant for an API: your app may not be its audience, and it may not even be a JWT. Sign users in from a validated ID token whose aud is your client.

• Decoding without verifying

  Base64-decoding the ID token and reading email skips the signature, issuer and audience checks, so anyone can forge a token. Verify against the provider's JWKS with a maintained library.

• Keying users by email

  Email addresses change and can be reassigned to someone else. Use the iss + sub pair as the stable identifier, and treat email as a profile attribute (check email_verified).

• Skipping state and nonce

  Without state the callback is open to login CSRF; without nonce, a captured ID token can be replayed into a new session. Generate both per request and compare them on return.

Sign-in is where most account takeovers begin. Building your own password login for a messaging dashboard means storing hashes, adding MFA and handling resets, and every leaver keeps working credentials until someone remembers to delete them. With OIDC the identity provider handles authentication and Two-Factor Authentication, your app receives a verifiable statement of who signed in, and disabling a person in the directory removes their access everywhere at once, which is exactly what auditors look for when agents can read customer chats.

• Cache the JWKS but refetch on an unknown kid, so provider key rotation never breaks sign-in.
• Allow a small clock skew, a minute or so, when checking exp and iat.
• Request only the claims you use; openid email is enough for most dashboards.
• Map directory groups to dashboard roles at sign-in, so access follows the person's job.