OIDC vs OAuth 2.0:

Analogies:

OAuth 2.0 is like a hotel key - it gives access to the room, but doesn't say who you are.

OpenID Connect is like a personal card - it proves who you are and provides basic information about you.

Basic concepts in OIDC:

• End User - The user who authenticates and gives access to their data
• Relying Party (RP) / Client - The application that wants to authenticate the user and receive information about them
• OpenID Provider (OP) - The server that authenticates the user and provides an ID Token
• ID Token - JWT token, which contains claims for the authenticated user
• UserInfo Endpoint - API endpoint, which returns additional information about the user
• Claims - Claims for the user (name, email, picture, etc.)

OIDC Authorization Code Flow:

1. 1

   Authentication Request

   The client redirects the user to the OP with OIDC parameters

2. 2

   User Authentication

   The user authenticates at the OpenID Provider

3. 3

   Authorization Response

   OP redirects back with authorization code

4. 4

   Token Request

   The client sends the authorization code for tokens

5. 5

   Token Response

   OP returns ID Token, Access Token and optionally Refresh Token

6. 6

   UserInfo Request

   The client uses the Access Token for the UserInfo endpoint

7. 7

   UserInfo Response

   OP returns information about the user

Standard Claims in OIDC:

Identity Claims

• sub - Subject - unique identifier of the user
• iss - Issuer - identifier of the OpenID Provider
• aud - Audience - for whom is the token intended
• exp - Expiration time
• iat - Issued at - time when the token was issued

Profile Claims

• name - Full name
• given_name - Given name
• family_name - Family name
• middle_name - Middle name
• nickname - Nickname
• preferred_username - Preferred username
• profile - Profile page URL
• picture - Profile picture URL
• website - Personal website URL
• gender - Gender
• birthdate - Birthdate
• zoneinfo - Time zone
• locale - Locale
• updated_at - When the profile was updated

Email Claims

• email - Email address
• email_verified - Whether the email is verified

Phone Claims

• phone_number - Phone number
• phone_number_verified - Whether the phone number is verified

Address Claims

• address - Address information

OIDC Scopes (Scopes):

• openid - Required - indicates that this is an OIDC request, not OAuth
• profile - Access to basic profile claims (name, family_name, picture, etc.)
• email - Access to email and email_verified claims
• address - Access to address claim
• phone - Access to phone_number and phone_number_verified claims
• offline_access - Issues a refresh token for long-term access

OIDC Endpoints:

• Authorization Endpoint - Starts the OIDC flow and authenticates the user
• Token Endpoint - Exchanges the authorization code for tokens
• UserInfo Endpoint - Returns claims for the authenticated user
• Discovery Endpoint - OIDC configuration
• JWKS Endpoint - JSON Web Key Set for signature validation
• End Session Endpoint - Ends the user's session

OIDC Discovery Document:

OpenID Providers publish a configuration document that describes their endpoints and supported functions.

Popular OpenID Providers:

• Google - https://accounts.google.com/.well-known/openid-configuration
• Microsoft - https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
• Auth0 - https://your-domain.auth0.com/.well-known/openid-configuration
• Okta - https://your-domain.okta.com/.well-known/openid-configuration
• GitHub - https://github.com/login/oauth/authorize
• Keycloak - https://your-keycloak.com/auth/realms/your-realm/.well-known/openid-configuration

Security best practices:

• Validate ID Token - Validate the signature with the JWKS endpoint
• Use PKCE - For all public clients, use Proof Key for Code Exchange
• Use HTTPS - Always use HTTPS for all communications
• Restrict scopes - Request only the necessary scopes for your application
• Restrict token lifetimes - Use short-lived access tokens and secure refresh tokens

Advantages of OpenID Connect: