OpenID Connect Concepts

Understanding identity and authentication with OpenID Connect.

OAuth vs OpenID Connect

Aspect
OAuth 2.0
OpenID Connect

Purpose

Authorization

Authentication

Question

"What can they do?"

"Who are they?"

Result

Access token

ID token + Access token

Use case

API access

User login

OpenID Connect (OIDC) is a thin layer on top of OAuth 2.0 that adds identity.

The Identity Layer

┌────────────────────────────────────────┐
│           OpenID Connect               │
│         (Authentication)               │
├────────────────────────────────────────┤
│              OAuth 2.0                 │
│          (Authorization)               │
└────────────────────────────────────────┘

OIDC adds:

  • ID Token - Proof of authentication

  • UserInfo Endpoint - User profile data

  • Standard Scopes - openid, profile, email

  • Discovery - Automatic configuration

The ID Token

The ID token is a JWT that proves authentication:

Key Claims

Claim
Description

iss

Who issued the token

sub

Unique user identifier

aud

Who the token is for

exp

When it expires

iat

When it was issued

auth_time

When user authenticated

nonce

Prevents replay attacks

Standard Scopes

Request identity information with scopes:

Scope
Claims

openid

sub (required)

profile

name, picture, etc.

email

email, email_verified

address

address

phone

phone_number

Authentication Flow

spinner

ID Token vs Access Token

Aspect
ID Token
Access Token

For

Client

Resource Server

Purpose

Prove identity

Authorize API calls

Validate

At login

On each request

Contains

User identity

Authorization grants

When to Use Which

UserInfo Endpoint

Get more user data with the access token:

Response:

ID Token vs UserInfo

Aspect
ID Token
UserInfo

When

Token response

Separate request

Format

JWT (signed)

JSON

Freshness

Point-in-time

Current values

Use ID token for authentication proof. Use UserInfo for current profile data.

Discovery

OIDC providers publish configuration:

Response:

Clients use discovery to automatically configure themselves.

Nonce

Prevents token replay attacks:

  1. Client generates random nonce

  2. Client sends nonce in authorization request

  3. Authority includes nonce in ID token

  4. Client verifies nonce matches

Authentication Patterns

Simple Login

Single Sign-On (SSO)

Silent Authentication

Security Considerations

Validate ID Tokens

Always validate:

  1. Signature - Using JWKS

  2. Issuer - Matches expected

  3. Audience - Contains your client ID

  4. Expiration - Not expired

  5. Nonce - If used, matches sent value

Don't Trust Claims Blindly

  • ID tokens are signed, not encrypted

  • Claims can be read by anyone

  • Don't put sensitive data in ID tokens

Use ID Token for Authentication Only

  • ID tokens prove identity at login time

  • Don't use ID tokens for API authorization

  • Use access tokens for API calls

Next Steps

Last updated

Was this helpful?