OpenID Connect
OAuth 2.0 tells your application what a user can access, but it doesn't tell you who they are. OpenID Connect (OIDC) solves this by adding an identity layer on top of OAuth.
Think of it this way: OAuth gives you a key to someone's house. OIDC also gives you their business card so you know whose house you're entering.
What OIDC Adds
OIDC introduces three key additions to OAuth. First, the ID token — a JWT containing user identity information. Second, a standardized UserInfo endpoint where you can fetch additional user details. Third, standardized claims — agreed-upon field names for common user attributes.
The ID Token
When you include openid in your OAuth scopes, you receive an ID token alongside the access token. Here's what one looks like decoded:
{
"iss": "https://accounts.google.com",
"sub": "1234567890",
"aud": "your-client-id",
"exp": 1623456789,
"iat": 1623453189,
"email": "user@example.com",
"name": "Alice Smith"
}
The sub (subject) claim is the user's unique identifier at that provider. The iss (issuer) tells you who created the token. The aud (audience) should match your client ID — if it doesn't, reject the token.
Validating ID Tokens
Never trust an ID token without validation. Your checklist should include verifying the cryptographic signature using the provider's public keys, checking that exp (expiration) hasn't passed, confirming iss matches your expected provider, and ensuring aud contains your client ID.
Most authentication libraries handle this automatically, but understanding what's being checked helps you debug issues and avoid security mistakes.
Standard Scopes and Claims
OIDC defines standard scopes that request specific claims. The openid scope is required and returns sub. The profile scope adds name, picture, and similar attributes. The email scope provides email and email_verified.
This standardization means your code works the same whether users log in with Google, Microsoft, or any OIDC-compliant provider.
When to Use OIDC
Use OIDC whenever you need to know who the user is — which is most authentication scenarios. If you only need to access a user's resources (like reading their calendar), plain OAuth suffices. If you need to identify them (like creating an account), you need OIDC.