OpenID Connect
Also known as: OIDC, OpenID, ID token, SSO protocol, Sign in with Google
OpenID Connect (OIDC) is an authentication protocol built on OAuth 2.0.
Where OAuth 2.0 answers 'what can this app access?', OIDC answers 'who is this user?' It provides a standardized ID token (a JWT) containing user identity information, enabling federated login across applications.
OpenID Connect, explained at three levels
At home
OpenID Connect is the protocol that makes 'Sign in with Google' work. Google not only grants the app access to your data (OAuth 2.0) but also tells the app exactly who you are -- your name, email, and profile picture -- in a standardized format the app can trust.
At work
OIDC is how enterprise SSO (Single Sign-On) works. Employees log in once to their company's identity provider (Okta, Azure AD), and that login works across all connected apps -- HR software, project management, business intelligence tools -- without logging in separately to each.
At home
OIDC adds an ID token to the OAuth 2.0 flow. The ID token is a JWT (JSON Web Token) signed by the identity provider, containing claims: sub (unique user ID), email, name, picture, and iat/exp (issued/expiry times). Applications verify the JWT's signature using the provider's public key, confirming it's genuine without calling the server again.
At work
OIDC discovery (/.well-known/openid-configuration) exposes the identity provider's endpoints and public keys as a JSON document, enabling dynamic client configuration. OIDC scopes: 'openid' (required, triggers OIDC), 'profile' (name, picture), 'email'. The UserInfo endpoint provides additional claims beyond the ID token.
At home
OIDC's ID token validation requires checking: signature (using the provider's JWKS), iss (issuer matches the expected provider), aud (audience matches your client_id), exp (not expired), and nonce (if used, matches to prevent replay attacks). Libraries handle this automatically; developers shouldn't implement validation manually.
At work
In federated enterprise identity, OIDC connects identity providers (Okta, Azure AD) to service providers (any OIDC-compliant app). The provider issues tokens; apps validate them offline using cached JWKS. Back-channel logout (RFC 9893) allows identity providers to notify apps when a session ends, enabling centralized session termination. OIDC FAPI (Financial-grade API) adds additional security requirements for banking and financial applications.
Real-world examples
At home
Aisha uses 'Sign in with Apple' for a recipe app. Apple's OIDC implementation sends the app a token confirming she's authenticated -- including an anonymized email relay address. She never shares her real email with the app.
At work
Thomas's company uses Okta as their identity provider. All their SaaS tools (Salesforce, Jira, Slack, GitHub) are configured as OIDC clients pointing to Okta. Employees log in once; Okta issues tokens for each app. Offboarding an employee disables their Okta account and immediately revokes access to all apps.
Common confusions
- OIDC and SAML are the same — Both enable SSO, but OIDC uses JSON tokens and REST APIs (modern, mobile-friendly), while SAML uses XML assertions and redirects (older, better supported in legacy enterprise apps). Many identity providers support both.
- You can use OAuth 2.0 alone for authentication — OAuth 2.0 access tokens don't tell you who the user is -- they only grant access. Without OIDC's ID token, you'd need to call the userinfo endpoint separately. OIDC was created specifically to fill this gap.
For analysts
OIDC is the foundation of enterprise SSO, which has direct operational impact -- when an OIDC integration breaks, analysts can't log into BI tools. Understanding the protocol helps BAs communicate clearly with IT about access issues.
History & origin
OpenID (the original version) launched in 2005 but had adoption challenges due to complexity. OpenID Connect launched in 2014, built on OAuth 2.0's foundations, making it simpler and more compatible with the modern API ecosystem. It quickly became the standard for identity federation, adopted by Google, Microsoft, Apple, and every major identity provider. OIDC is the protocol behind 'Sign in with Google', 'Sign in with Apple', and enterprise SSO from Okta and Azure AD.