What is OpenID Connect (OIDC)?
OpenID Connect is an identity layer on top of OAuth 2.0. It lets a client verify an end user's authentication and receive identity claims in an ID token. OAuth access tokens authorize calls to resource servers. An ID token is for the client and is not an API access token. A secure implementation validates the issuer, audience, signature, expiry, nonce, and flow-specific requirements.
Why it matters
OIDC gives applications an interoperable way to delegate sign-in to an identity provider. It separates user authentication from the application's local account and password system.
How it works
- The client sends the user to the OpenID Provider with a registered redirect URI, state, nonce, and requested scope.
- After user authentication, the client receives an authorization response and, in the authorization code flow, exchanges the code at the token endpoint.
- The client validates the ID token and uses its claims for the sign-in session. It uses an access token, not the ID token, when it calls an authorized resource server.
Example
An employee opens a protected application. Pomerium sends the employee to the company's OIDC identity provider, completes the sign-in flow, and creates a local Pomerium session from the verified result.
Pomerium boundary
Pomerium is an OIDC client, not an identity provider. It can use an OIDC-compatible identity provider to authenticate users, store relevant session data, and make OIDC claims available to Pomerium authorization policy.
Limits and non-claims
- OIDC authenticates the user to the client. The application and resource servers still need authorization policy.
- Incorrect issuer, audience, signature, redirect URI, state, or nonce validation can break the protocol's security.
- An OIDC sign-out or expired ID token does not by itself define every application and resource session lifetime.
Evaluation checklist
- Does the client validate issuer, client identifier, redirect URI, state, nonce, code, and ID token?
- Does it keep the ID token sign-in role separate from access-token use at an API?
- Can claim mapping, account linking, logout, recovery, or a local login bypass the intended identity policy?
