OpenID Connect expliqué : flows, JWT, PKCE, sécurité 2026

Scénario OAuth 2.0 :
  Utilisateur  → autorise App Comptable
  App Comptable → reçoit Access Token → appelle API bancaire
  API Bancaire → vérifie Access Token → retourne données

Scénario OIDC :
  Utilisateur  → se connecte via Google sur App MonSite
  Google → émet Access Token + ID Token au client MonSite
  MonSite → lit l'ID Token (JWT) → connaît l'identité vérifiée

OpenID Provider (OP)
  aka Authorization Server, Identity Provider (IdP)
  Exemple : Google, Microsoft Entra ID, Okta, Auth0, Keycloak
  Rôle : authentifier l'utilisateur, émettre tokens
 
Relying Party (RP)
  aka Client Application
  Exemple : votre application web, mobile, SPA
  Rôle : consommer l'ID Token pour connaître l'utilisateur
 
End User
  L'utilisateur final qui s'authentifie

Étape 1 - Client génère PKCE :
  code_verifier = random 43-128 chars
  code_challenge = BASE64URL(SHA256(code_verifier))
 
Étape 2 - Redirection authorization :
  GET https://op.example/authorize
    ?response_type=code
    &client_id=xyz
    &redirect_uri=https://app.example/callback
    &scope=openid profile email
    &state=<csrf_random>
    &nonce=<replay_protection_random>
    &code_challenge=<hash>
    &code_challenge_method=S256
 
Étape 3 - Utilisateur s'authentifie chez OP
  Login + MFA éventuel
 
Étape 4 - OP redirige vers le client avec un code :
  GET https://app.example/callback?code=ABC123&state=<csrf_random>
 
Étape 5 - Client échange code contre tokens (backend ou SPA PKCE) :
  POST https://op.example/token
    grant_type=authorization_code
    code=ABC123
    redirect_uri=https://app.example/callback
    client_id=xyz
    code_verifier=<original_secret>
 
Étape 6 - OP valide code_verifier vs code_challenge, retourne :
  {
    "access_token": "...",
    "id_token": "eyJhbG...",
    "refresh_token": "...",
    "token_type": "Bearer",
    "expires_in": 3600
  }

POST https://op.example/token
  grant_type=client_credentials
  client_id=service-a
  client_secret=...
 
Réponse :
  access_token + expires_in (pas d'ID Token car pas d'utilisateur)

Device → POST /device_authorization → reçoit user_code, device_code, verification_uri
TV affiche : « Allez sur https://op.example/device et entrez ABC-123 »
Utilisateur se connecte sur smartphone avec ce code
Device polle /token avec device_code jusqu'à obtention

Pourquoi déprécié :
  Token dans URL = fuite via Referer, logs serveur, extensions navigateur
  Pas de preuve de possession = replay possible
  Authorization Code + PKCE résout tous ces problèmes

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyMyJ9
.
eyJpc3MiOiJodHRwczovL29wLmV4YW1wbGUiLCJzdWIiOiJ1c2VyXzEyMyIsImF1ZCI6ImNsaWVudF94eXoiLCJleHAiOjE3MzQ5MDAwMDAsImlhdCI6MTczNDg5NjQwMCwibm9uY2UiOiJhYmMxMjMiLCJlbWFpbCI6ImFsaWNlQGV4YW1wbGUuY29tIn0
.
signature_RSA256_base64url

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "123"
}

{
  "iss": "https://op.example",
  "sub": "user_123",
  "aud": "client_xyz",
  "exp": 1734900000,
  "iat": 1734896400,
  "nonce": "abc123",
  "email": "alice@example.com",
  "email_verified": true,
  "name": "Alice Dupont"
}

# Exemple Python avec PyJWT + cryptography
import jwt
import requests
 
# 1. Récupérer JWKS de l'OpenID Provider
JWKS_URL = "https://op.example/.well-known/jwks.json"
jwks_client = jwt.PyJWKClient(JWKS_URL)
 
def validate_id_token(id_token: str, expected_client_id: str, nonce_sent: str) -> dict:
    # 2. Obtenir la clé publique correspondant au kid du header
    signing_key = jwks_client.get_signing_key_from_jwt(id_token)
 
    # 3. Valider signature, algorithme, issuer, audience, expiration
    payload = jwt.decode(
        id_token,
        signing_key.key,
        algorithms=["RS256"],  # JAMAIS ["none"], jamais de mix HS256/RS256
        audience=expected_client_id,
        issuer="https://op.example",
        options={"require": ["exp", "iat", "iss", "aud", "sub"]},
    )
 
    # 4. Vérifier le nonce
    if payload.get("nonce") != nonce_sent:
        raise ValueError("nonce mismatch - possible replay attack")
 
    return payload

openid         : obligatoire pour déclencher OIDC (sinon OAuth pur)
profile        : name, family_name, given_name, picture, updated_at
email          : email, email_verified
phone          : phone_number, phone_number_verified
address        : address (structured)
 
Scopes custom :
  Exemples : "read:invoices", "write:reports"
  Définis par chaque OpenID Provider, reçus dans l'Access Token

Parade :
  Toujours whitelister les algorithmes acceptés (RS256, ES256)
  Bannir explicitement "none"
  Utiliser des bibliothèques qui refusent "none" par défaut (PyJWT 2.0+)

Parade :
  Toujours passer explicitement algorithms=["RS256"]
  Ne jamais déduire l'algorithme du header uniquement

Parade :
  Whitelister strictement les redirect_uri côté OP (exact match, pas regex)
  Ne pas accepter les wildcards sur les redirect_uri
  Valider côté client que le state correspond

Parade :
  Toujours générer un state aléatoire et le valider au callback
  Random cryptographique, au moins 128 bits d'entropie
  Lier le state à la session utilisateur (cookie)

Parade :
  Toujours inclure un nonce aléatoire dans la requête authorize
  Valider qu'il est présent dans l'ID Token reçu
  Ne jamais réutiliser un nonce

Parade :
  L'ID Token a aud=client_id (pas l'API)
  L'Access Token a aud=resource_server (l'API)
  L'API valide explicitement aud et refuse les tokens avec mauvaise audience

Parade :
  Whitelister les domaines acceptés côté OP
  Bloquer les IP privées et métadonnées cloud
  Utiliser les recommandations OWASP SSRF Cheat Sheet

name: deploy-to-aws
on: [push]
permissions:
  id-token: write       # requis pour émettre le JWT OIDC
  contents: read
 
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Configure AWS credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789:role/github-actions-deploy
          aws-region: eu-west-3
      - run: aws s3 sync ./dist s3://my-bucket/

GitHub Actions              : ✓ natif depuis 2021
GitLab CI                   : ✓ natif depuis 15.7 (2022)
CircleCI                    : ✓ natif depuis 2022
Bitbucket Pipelines         : ✓ natif
Jenkins                     : ✓ via plugin OIDC
Terraform Cloud / HCP       : ✓ Workload Identity natif
 
Destinations supportées :
  AWS IAM Identity Provider
  GCP Workload Identity Federation
  Azure Federated Credentials
  HashiCorp Vault JWT/OIDC auth method
  Kubernetes ServiceAccount Projected Tokens

JavaScript/TypeScript :
  oidc-client-ts (successor oidc-client-js)
  openid-client (Node.js backend)
  NextAuth.js (Next.js)
  Auth.js (framework-agnostic)
 
Python :
  Authlib                    : complet et maintenu
  requests-oauthlib         : léger
  mozilla-django-oidc        : Django
 
Java :
  Nimbus OAuth 2.0 SDK       : référence
  Spring Security OAuth2     : intégration Spring
 
Go :
  golang.org/x/oauth2
  github.com/coreos/go-oidc
 
Ruby :
  omniauth-openid-connect
 
Rust :
  openidconnect-rs

Keycloak (Red Hat OSS)       : leader OSS, mature
Ory Hydra + Kratos           : modulaire, cloud-native
Authentik (OSS)              : moderne, alternative
Zitadel (OSS + SaaS)         : multi-tenant natif
Authelia (OSS)               : léger, self-hosting homelab

Auth0 (Okta)                 : leader SaaS
Microsoft Entra ID            : dominant entreprise M365
Okta Customer Identity       : enterprise
Google Identity Platform     : GCP, grand public via Google Sign-In
Amazon Cognito               : AWS-friendly
Clerk                        : dev-friendly, moderne
Stytch                       : passwordless-first
WorkOS                       : SSO B2B dev-friendly