OpenID Connect (OIDC)
What is OpenID Connect (OIDC)?
OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0 that provides standardized authentication. It enables applications to verify user identities and obtain basic profile information in a secure, interoperable way. OIDC is widely used for single sign-on (SSO) and federated identity scenarios.
How OIDC Works
OIDC extends OAuth 2.0 by adding an ID token (a JWT) that contains user identity information. The flow is similar to OAuth 2.0 but includes additional identity-specific components:
- Authentication Request: Client requests user authentication
- User Authentication: Authorization server authenticates the user
- Authorization Grant: User approves the request
- Token Response: Client receives an ID token + access token
- UserInfo Request: Client retrieves additional user details (optional)
User → (1) Login Request → Client
Client → (2) Redirect to OIDC Provider → User
User → (3) Authenticate → OIDC Provider
OIDC Provider → (4) ID Token + Access Token → Client
Client → (5) Validate ID Token → User Identity Confirmed
Client → (6) Request UserInfo (Optional) → OIDC Provider
Key OIDC Components
1. ID Token
- A JWT containing user identity claims (e.g.,
sub,email,name) - Signed by the OIDC provider to ensure integrity
- Example:
{ "sub": "1234567890", "name": "John Doe", "email": "john@example.com", "iat": 1516239022, "exp": 1516242622 }
2. UserInfo Endpoint
- Provides additional user claims (e.g.,
address,phone_number) - Requires the access token for authorization
3. Scopes and Claims
- Scopes: Define the level of access (e.g.,
openid,profile,email) - Claims: Individual pieces of user information (e.g.,
name,email_verified)
| Scope | Claims Included |
|---|---|
openid | Required for OIDC (includes sub claim) |
profile | name, family_name, given_name, picture, locale, etc. |
email | email, email_verified |
address | address (street, city, country, etc.) |
phone | phone_number, phone_number_verified |
4. OIDC Flows
OIDC supports multiple authentication flows, all based on OAuth 2.0 grant types:
| Flow | Use Case | Security Level |
|---|---|---|
| Authorization Code | Web apps, server-side apps (most secure) | High |
| Implicit | Single-page apps (deprecated in OIDC Core 1.0) | Low |
| Hybrid | Combines authorization code and ID token in the front channel | Medium |
OIDC vs. OAuth 2.0
| Feature | OAuth 2.0 | OpenID Connect (OIDC) |
|---|---|---|
| Purpose | Authorization (access to resources) | Authentication (identity) |
| Tokens | Access token | Access token + ID token |
| User Info | Not standardized | Standardized claims |
| Discovery | No standard discovery | .well-known/openid-configuration |
| Use Case | API access | User login and profile data |
OIDC Security Considerations
1. ID Token Validation
- Verify the signature (using the provider's public keys)
- Check the issuer (
iss) matches the expected OIDC provider - Validate the audience (
aud) matches your client ID - Ensure the token hasn't expired (
exp) - Check the nonce (
nonce) to prevent replay attacks
Example (Node.js with openid-client):
const { Issuer } = require('openid-client');
const validateIdToken = async (idToken, client) => {
const tokenSet = await client.validateIdToken(idToken);
if (tokenSet.nonce !== expectedNonce) {
throw new Error('Invalid nonce');
}
return tokenSet.claims();
};
2. Secure Token Storage
- Store tokens in HTTP-only, Secure, SameSite cookies
- Avoid localStorage (vulnerable to XSS)
3. Prevent Token Leakage
- Use short-lived tokens (e.g., ID tokens expire in 5 minutes)
- Never expose tokens in URLs or logs
4. Use PKCE for Public Clients
- Protects against authorization code interception
- Required for mobile and single-page apps
5. Implement Logout
- RP-Initiated Logout: Client requests user logout from the OIDC provider
- Front-Channel Logout: Provider notifies other clients via iframes
- Back-Channel Logout: Provider sends logout tokens to clients
OIDC Best Practices
1. Use the Authorization Code Flow
- The most secure flow for web and mobile apps
- Combine with PKCE for enhanced security
2. Validate All Tokens
- Always validate ID tokens and access tokens
- Use the provider's JWKS endpoint to verify signatures
3. Implement Session Management
- Use session cookies with short expiration times
- Support single logout to terminate all sessions
4. Secure Redirect URIs
- Register exact redirect URIs (no wildcards)
- Validate URIs on the server side
5. Monitor and Log
- Track authentication attempts to detect anomalies
- Log failed attempts and token validation errors
6. Use Discovery for Configuration
- Leverage the OIDC Discovery endpoint (
/.well-known/openid-configuration) - Example:
https://auth.example.com/.well-known/openid-configuration
Real-World Examples
Social Login
- "Login with Google" uses OIDC to authenticate users and retrieve profile data
- Scopes:
openid email profile
Enterprise SSO
- Companies use OIDC for single sign-on across internal apps
- Example: Employees log in once to access email, HR, and project tools
Government Services
- Login.gov uses OIDC to provide secure authentication for U.S. government services
- Supports multi-factor authentication (MFA) for high-security applications
OIDC Extensions and Standards
- OIDC Core: Defines the core authentication flows (RFC 6749 + OIDC extensions)
- OIDC Discovery: Standardized provider configuration (RFC 8414)
- OIDC Dynamic Registration: Client registration at runtime
- OIDC Session Management: Defines logout and session monitoring
- OIDC Front-Channel Logout: Logout via iframes
- OIDC Back-Channel Logout: Logout via direct server communication
Related Concepts
- OAuth 2.0: Authorization framework that OIDC builds upon
- JWT (JSON Web Token): Token format used for ID tokens in OIDC
- SAML (Security Assertion Markup Language): Alternative authentication protocol
- Multi-Factor Authentication (MFA): Additional security layer for OIDC authentication
- Session Management: Maintaining secure sessions with OIDC
- WebSockets Security: Securing real-time communication with OIDC authentication
- Cross-Site Request Forgery (CSRF): Attack prevented by OIDC best practices
Further Reading
Open Redirect
Open Redirect is a web security vulnerability that allows attackers to redirect users to malicious websites, enabling phishing attacks, malware distribution, and credential theft by exploiting unvalidated redirect parameters.
OWASP Core Rule Set (CRS)
Open-source set of generic attack detection rules for web application firewalls.
