OpenID Connect (OIDC): The Identity Layer on Top of OAuth 2.0

OAuth 2.0 was designed strictly as an authorization protocol, not an authentication protocol. An OAuth 2.0 access token merely signifies that some client is authorized to perform some operations on a server. It gives the client zero standardized information about who the user is, when they logged in, or how they authenticated.

Before OpenID Connect, every tech company invented proprietary hacks:

• Facebook created graph.facebook.com/me.
• GitHub created api.github.com/user.
• Twitter created custom user profile JSON endpoints.

Developers had to write separate custom wrappers for every provider. OpenID Connect (OIDC 1.0) solved this by creating an open, standardized identity layer built directly on top of the OAuth 2.0 framework. By adding the scope=openid parameter to an OAuth 2.0 request, the Authorization Server becomes an OpenID Provider (OP) and returns a standardized ID Token.

One of the most dangerous beginner security bugs is sending the ID Token to an API backend for authorization, or using an Access Token on the client UI for authentication:

An OIDC ID Token is a cryptographically signed JWT containing standardized claims defined in RFC 7519 and the OIDC Core specification:

json
Copy
{
  "iss": "https://accounts.google.com",
  "sub": "109823491823901238",
  "aud": "my-spa-client-id-889.apps.googleusercontent.com",
  "exp": 1714003600,
  "iat": 1714000000,
  "auth_time": 1713999950,
  "nonce": "n-0S6_WzA2Mj",
  "at_hash": "f9m_28v1Lq08_Xz9Q",
  "email": "alice@example.com",
  "email_verified": true,
  "name": "Alice Smith",
  "picture": "https://lh3.googleusercontent.com/a/alice-avatar.png"
}

Key Security Claims:

• nonce (Number Used Once): A client-generated random string included in the authorization request and echoed back in the ID token to prevent Replay Attacks.
• at_hash (Access Token Hash): Base64URL encoding of the left-most half of the hash of the access_token. It cryptographically binds the ID token to the specific access token issued alongside it.
• auth_time: The epoch timestamp when the user actually completed the login challenge (allows apps to enforce re-authentication if the session is stale).

OIDC eliminates hardcoded endpoint configurations through the OpenID Connect Discovery 1.0 specification. Every compliant provider publishes its configuration at the well-known URL: https://<domain>/.well-known/openid-configuration

json
Copy
{
  "issuer": "https://accounts.google.com",
  "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
  "token_endpoint": "https://oauth2.googleapis.com/token",
  "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
  "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
  "response_types_supported": ["code", "token", "id_token", "code id_token"],
  "subject_types_supported": ["public"],
  "id_token_signing_alg_values_supported": ["RS256"]
}

Benefits of Discovery:

1. Zero-Configuration Client Setup: Applications simply configure the issuer URL; client libraries automatically fetch the correct authorization, token, and JWKS public certificate endpoints.
2. Seamless Key & Endpoint Migration: If an IdP rotates endpoints or migration certificates, client applications adapt automatically without manual config edits.