OpenID Connect (OIDC)
debt(d7/e5/b5/t7)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints indicate automated detection is 'no' and the tool listed (semgrep) would require custom rules to catch patterns like using access tokens for identity or skipping ID token validation. These misuses are silent in normal operation — a user appears to log in successfully even when auth is done incorrectly — and won't surface until a security review or penetration test.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix points to switching from OAuth2 access-token-based identity to OIDC ID token parsing, but the common_mistakes reveal multiple layered issues: token signature validation, audience claim checking, nonce verification. Correcting all of these touches auth middleware, session handling, and token validation logic across a component — more than a single-line fix but typically contained within the auth subsystem.
Closest to 'persistent productivity tax' (b5). Applies to web and API contexts broadly (applies_to: web, api). An incorrectly implemented auth flow shapes every feature that depends on knowing who the user is — session management, access control, user data retrieval. However, it is typically encapsulated in an auth layer rather than diffused across the entire codebase, so it doesn't reach b7.
Closest to 'serious trap (contradicts how a similar concept works elsewhere)' (t7). The misconception field states explicitly that OAuth 2.0 and OIDC are conflated — OAuth 2.0 access tokens are widely used for API authorization, so developers familiar with OAuth naturally (but incorrectly) use access tokens for identity. The 'obvious' pattern from OAuth experience leads directly to an insecure implementation. Multiple compounding mistakes (no signature validation, no aud check, no nonce) make this a serious trap just short of catastrophic.
Also Known As
TL;DR
Explanation
OpenID Connect adds to OAuth 2.0: an ID token (JWT containing user identity claims — sub, name, email, picture), a UserInfo endpoint (fetch additional claims), and a discovery document (/.well-known/openid-configuration lists all endpoints). The ID token is for the client application (to know who logged in); the access token is for calling APIs. Flow: same as OAuth 2.0 authorization_code flow but with openid scope added. PHP libraries: league/oauth2-client, thephpleague/oauth2-google, lcobucci/jwt for token validation.
Common Misconception
Why It Matters
Common Mistakes
- Using the OAuth access token to identify the user — access tokens are for calling APIs, not authentication.
- Not validating the ID token signature — anyone can craft a JWT without signature validation.
- Not checking the aud (audience) claim — ID tokens from other clients can be replayed.
- Not verifying the nonce — prevents ID token replay attacks.
Code Examples
// Using access token for identity — wrong:
$accessToken = $oauth->getAccessToken('authorization_code', ['code' => $_GET['code']]);
// Access token is opaque — you don't know who this user is from the token alone
$user = $googleApi->getUser($accessToken->getToken()); // Extra API call needed
// Token may belong to any Google user// OIDC — ID token contains verified identity:
$provider = new Google(['clientId' => ..., 'redirectUri' => ...]);
$tokens = $provider->getAccessToken('authorization_code', [
'code' => $_GET['code'],
'scope' => 'openid email profile',
]);
// ID token: JWT with signed identity claims
$idToken = $tokens->getValues()['id_token'];
$claims = $jwtValidator->validate($idToken, [
'iss' => 'https://accounts.google.com',
'aud' => CLIENT_ID,
'nonce' => $_SESSION['oauth_nonce'],
]);
$userId = $claims['sub']; // Stable user identifier