🔁 Module 3 — Le flux Authorization Code + PKCE en détail

Bonne lecture et bon apprentissage ! Junior TSAFACK – 12/09/2026 ⏱️ Temps de lecture estimé : 8 minutes

Reprenons le flux Authorization Code identifié au Module 2, cette fois avec les 4 acteurs (Browser, Client, Authorization Server, Resource Server) et chaque échange HTTP.

🗺️ Le flux complet, étape par étape

┌─────────┐                ┌────────┐              ┌───────────────────┐
│ Browser │                │ Client │              │ Authorization      │
│         │                │(backend)│              │ Server             │
└─────────┘                └────────┘              └───────────────────┘
     │                          │                            │
     │──① GET /my-data─────────►│                            │
     │                          │                            │
     │◄─② Redirection : "connectez-vous à l'Authorization Server"
     │                          │                            │
     │──③ GET /authorize (client_id, redirect_uri, state, code_challenge)────►│
     │                          │                            │
     │         (l'utilisateur s'authentifie et donne son consentement)
     │                          │                            │
     │◄────④ Redirection avec ?code=XXXX&state=xyz123─────────│
     │                          │                            │
     │──⑤ Le navigateur transmet le code au Client (via redirect_uri)──►│
     │                          │                            │
     │                          │──⑥ POST /token (code, client_id,      │
     │                          │    client_secret, code_verifier)─────►│
     │                          │                            │
     │                          │◄────⑦ access_token─────────│
     │                          │                            │
     │                          │──⑧ GET /userinfo (Bearer access_token)──► Resource Server
     │                          │                            │
     │◄─⑨ "Voici vos données !"─│                            │

Décortiquons les points essentiels :

Étape ③ : c’est ici qu’apparaît code_challenge — nous y revenons juste après (PKCE).
Étape ④ : le serveur d’autorisation ne renvoie jamais l’Access Token directement au navigateur — seulement un code, de courte durée de vie (souvent 60 secondes) et à usage unique.
Étape ⑥ : c’est le Client backend, jamais le navigateur, qui échange ce code contre un token — cet échange nécessite le client_secret, que le navigateur ne connaît jamais.
state (étapes ③ et ④) : une valeur aléatoire générée par le Client avant la redirection, qu’il vérifie être identique au retour. Sans elle, un attaquant pourrait rediriger la victime vers un /callback avec son propre code d’autorisation, la faisant sans le savoir s’authentifier sur le compte de l’attaquant (une attaque appelée CSRF sur le flux OAuth).

🔒 Pourquoi PKCE ?

PKCE (Proof Key for Code Exchange, prononcé « pixy », RFC 7636) répond à un problème précis : et si un attaquant parvenait à intercepter le code d’autorisation de l’étape ④ (une app mobile mal configurée, un malware sur l’appareil qui intercepte les redirections inter-applications…) ? Sans protection supplémentaire, il pourrait l’échanger lui-même contre un Access Token à l’étape ⑥.

L’idée de PKCE : avant même l’étape ③, le Client génère un secret éphémère, jamais transmis en clair pendant la partie « publique » du flux :

1. Le Client genere un "code_verifier" : une chaine aleatoire (garde secrete)
2. Il calcule "code_challenge = SHA256(code_verifier)", encode en base64url
3. Etape ③ : le Client envoie le code_challenge (le hash, pas le secret) a /authorize
4. Etape ⑥ : le Client envoie le code_verifier (le secret original) a /token
5. Le serveur recalcule SHA256(code_verifier) et verifie qu'il correspond
   au code_challenge recu a l'etape ③

Un attaquant qui intercepte uniquement le code (étape ④) ne peut rien en faire : il ne connaît pas le code_verifier original, seulement son empreinte (code_challenge), qui — comme toute fonction de hachage — ne peut pas être inversée. C’est mathématiquement le même principe qu’un mot de passe stocké haché plutôt qu’en clair.

🧠 À retenir

Le navigateur ne voit jamais l’Access Token avant que le Client (backend) ne l’ait obtenu de manière privée à l’étape ⑥.
state protège contre une injection de code d’autorisation par un attaquant.
PKCE protège contre l’interception du code d’autorisation lui-même, en liant sa validité à un secret que seul le Client d’origine connaît.

Prochaine étape

Assez de diagrammes — au Module 4, nous allons réellement exécuter ce flux complet (Authorization Server + Client, en Python), avec PKCE, et provoquer volontairement chaque cas d’erreur pour observer les réponses réelles.

👉 Module 4 : Mise en pratique en Python