Quick answer
OpenID Connect (OIDC) is an identity layer built on top of the OAuth 2.0 authorization framework that enables clients to verify the identity of an end-user and obtain basic profile information via a standard REST/JSON and JWT-based protocol.
Why OIDC matters
OIDC standardizes authentication so applications can rely on a single, secure method to sign users in, receive identity data, and integrate with third-party identity providers (IdPs) like Okta, Auth0, Azure AD, and Salesforce. It solves the common problem of federated sign-in and user profile retrieval while leveraging OAuth 2.0 for authorization.
Core concepts
– Identity Provider (IdP): the server that authenticates the user and issues tokens.
– Relying Party (RP) / Client: the application that requests authentication and tokens.
– ID Token: a JWT that contains identity claims (who the user is).
– Access Token: used to access protected APIs (issued by OAuth 2.0).
– Refresh Token: used to obtain new access tokens without user interaction (optional).
Important OIDC endpoints
– Authorization Endpoint: where the user authenticates and consents.
– Token Endpoint: exchanges authorization codes for tokens.
– UserInfo Endpoint: returns standard profile claims about the user.
– Discovery Endpoint (.well-known/openid-configuration): metadata discovery for endpoints and supported features.
Common flows
– Authorization Code Flow: recommended for server-side web apps and SPAs (with PKCE).
– Implicit Flow: legacy, not recommended for new apps.
– Hybrid Flow: mix of code and tokens — used when immediate ID token and code are both needed.
– Client Credentials: for machine-to-machine (no user identity) — not OIDC-specific but part of OAuth 2.0.
Sample discovery URL and ID token (JWT) structure
Discovery URL example:
https://YOUR_IDP/.well-known/openid-configuration
Decoded ID token (JWT) parts: header.payload.signature — payload contains claims:
{
"iss": "https://idp.example.com",
"sub": "248289761001",
"aud": "your-client-id",
"exp": 1311281970,
"iat": 1311280970,
"auth_time": 1311280969,
"name": "Jane Doe",
"email": "[email protected]"
}
Scopes and claims
– Scopes: openid (required), profile, email, address, phone.
– Claims: pieces of identity information returned either in the ID token or from the UserInfo endpoint.
Security considerations
– Always validate the ID token: issuer (iss), audience (aud), signature, and exp/iat claims.
– Use PKCE for public clients (mobile & SPA) to mitigate code interception.
– Prefer Authorization Code Flow over Implicit Flow.
– Use HTTPS and validate discovery metadata and JWKS keys.
How OIDC differs from OAuth 2.0
OAuth 2.0 is an authorization framework (delegation of access). OIDC adds an identity layer on top, providing a standardized ID token (JWT), standard claims, and discovery metadata so clients can authenticate users in a consistent, interoperable way.
When to use OIDC
Use OIDC whenever you need to authenticate users (single sign-on, social login, enterprise SSO) and obtain consistent user profile data without implementing custom authentication logic.
Further reading
Official spec: https://openid.net/connect/ — check the discovery, ID Token, and Core specs for implementation details.