OIDC

OpenID Connect — Authorization Code Flow

OpenID Connect 1.0 is an identity layer built on top of OAuth 2.0. Where OAuth 2.0 answers 'what can this client do?', OIDC answers 'who is this user?'. The RP (Relying Party) obtains an ID Token — a signed JWT containing the user's identity — alongside the standard OAuth access token. Key OIDC additions: the 'openid' scope, nonce (replay protection), ID Token, at_hash (token binding), and the UserInfo endpoint.

OpenID Connect Core 1.0

GET https://app.example.com/login302

The user clicks 'Sign In'. The RP generates a nonce (ID Token replay guard) and PKCE code_verifier, then redirects the browser to the OP's /authorize endpoint with scope=openid to signal an OIDC request.

• OIDC Core §3.1.2.1: scope MUST include 'openid'. Without it, the OP will not issue an ID Token.

• OIDC Core §3.1.2.1: The nonce is OPTIONAL in the Authorization Code flow but recommended — it mitigates ID Token replay and injection attacks by binding the token to the session.

• The RP stores the nonce (or its hash) and state in an HttpOnly Secure cookie before redirecting.

• response_type=code means the authorization code flow — no tokens appear in the redirect URL, keeping them out of browser history.

1 / 6

speed

Step 1: GET / (Sign In clicked)

Request / response

GEThttps://app.example.com/login

text/html

Cryptographic Signature

Construction Steps

1. 1. scope=openid — the OIDC signal

scope = "openid profile email"

The presence of 'openid' in scope is what activates OIDC.
Without it this is a plain OAuth 2.0 request and no ID Token
will be issued.

  openid   → required for OIDC; triggers ID Token issuance
  profile  → name, picture, locale, updated_at, etc.
  email    → email, email_verified

Additional standard OIDC scopes: address, phone, offline_access

2. 2. nonce — ID Token replay protection

nonce = "n-0S6_WzA2Mj"  (cryptographically random)

The nonce is a one-time value the RP generates and stores.
The OP MUST include the nonce in the ID Token payload.
The RP MUST verify the ID Token nonce matches the stored value.

This prevents ID Token replay attacks: an attacker who
intercepts an ID Token cannot replay it at a different RP
or in a different session because the nonce won't match.

Note: The RP stores a HASH of the nonce in the session
(not the plain value) to avoid leaking it if the session is
compromised. The plain nonce is sent in the authorization
request and verified against the ID Token.

3. 3. PKCE (code_challenge) — code interception protection

code_verifier  = "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
code_challenge = BASE64URL(SHA-256(code_verifier))
               = "E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM"

PKCE (RFC 7636) protects the authorization code. Because OIDC
flows return an ID Token via the code, protecting the code
also protects the identity assertion.

OIDC + PKCE is the recommended combination for all client types.
See the OAuth 2.0 Authorization Code + PKCE flow for
full PKCE derivation details.

Signature Base String

scope=openid profile email, nonce=n-0S6_WzA2Mj, code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

Signing Key

RP generates nonce + PKCE before redirecting

Signature Output

Authorization request with openid scope, nonce, and code_challenge