OpenID Connect Flows (OIDC)

OpenID Connect (OIDC) définit plusieurs flows (flux d'authentification) selon le type de client (web server, SPA, mobile, native). Chaque flow a son use case, niveau sécurité, et trade-offs. OAuth 2.1 (in progress) consolide les meilleurs practices, déprécie les flows insécurisés.

Flows principaux :

(1) **Authorization Code Flow** — le standard moderne pour la plupart des cas.
- Web app avec backend : flow classique, code exchanged for tokens via server-to-server (client secret protected backend).
- SPA / Mobile : Authorization Code + PKCE (no client secret, cryptographic proof prevents code theft).
- Steps : Client → /authorize (redirect avec response_type=code) → User auth at IdP → Redirect back avec code → Client POST /token avec code → Receives access_token, id_token, refresh_token.

(2) **Implicit Flow** — DEPRECATED. Tokens returned directly in URL fragment (#access_token=...). Leakage risk via Referer, history, logs. OAuth 2.1 supprime. Used historiquement pour SPAs avant PKCE.

(3) **Hybrid Flow** — Code + ID Token in single response. Allows client to verify ID token immediately while keeping code for full token retrieval. Niche use cases.

(4) **Client Credentials Flow** — machine-to-machine, no user involved. Service account authentication. POST /token avec grant_type=client_credentials.

(5) **Resource Owner Password Credentials (ROPC)** — user provides username+password directly to client app. DEPRECATED — defeats SSO purpose, dangerous. Only for legacy migration.

(6) **Device Authorization Flow** (RFC 8628) — for devices without browser (smart TV, CLI). Display code, user enters at separate device.

(7) **CIBA (Client-Initiated Backchannel Authentication)** — server pushes auth request to user's authenticator device. Used in financial-grade.

PKCE (Proof Key for Code Exchange, RFC 7636) — extension critical pour Authorization Code Flow protected even sans client secret :
(1) Client génère **code_verifier** random 43-128 chars.
(2) Compute **code_challenge** = base64url(SHA256(code_verifier)).
(3) Send code_challenge avec /authorize request.
(4) IdP stores hash.
(5) Client POST /token with code AND code_verifier original.
(6) IdP verify SHA256(code_verifier) == stored code_challenge.
(7) Attacker intercepting code can't redeem without code_verifier.

PKCE now MANDATORY pour all OAuth/OIDC clients (web, SPA, mobile, native) per OAuth 2.1.

Claims dans ID Token (JWT) : `iss` (issuer), `sub` (subject), `aud` (audience), `exp`, `iat`, `auth_time`, `nonce`, custom claims (email, name, picture).

Voir oauth-attacks entry pour vulnerabilities. Compétences SC-300, AZ-500, CISSP.