Diagramme de flux OAuth 2.0 : authorization code avec PKCE, étape par étape

OAuth 2.0 est facile à utiliser et difficile à se représenter. Un bouton de connexion déclenche des redirections entre trois ou quatre parties, chacune avec des paramètres aux noms proches, et la plupart des bugs viennent d'une partie qui saute un contrôle qu'elle aurait dû faire. Un diagramme de séquence est la façon la plus claire de voir qui envoie quoi à qui, et dans quel ordre.

Cet article dessine le flux à utiliser aujourd'hui pour presque tous les clients : l'authorization code grant avec PKCE. Il parcourt chaque étape, explique ce que vérifie chaque partie et liste les anciens flux que les recommandations actuelles demandent d'abandonner.

Les quatre parties

Le client ne voit jamais le mot de passe de l'utilisateur. C'est tout l'intérêt d'OAuth : le serveur d'autorisation authentifie l'utilisateur et remet au client un jeton de portée et de durée limitées.

Quel flux en 2026

Le cadre OAuth 2.0 d'origine, la RFC 6749, définissait plusieurs grants. La OAuth 2.0 Security Best Current Practice, RFC 9700, publiée en janvier 2025, restreint le choix :

• Authorization code avec PKCE pour la connexion des utilisateurs, depuis tout type de client. Les clients publics (applications mobiles, single-page apps) doivent utiliser PKCE ; pour les clients confidentiels qui ont un secret côté serveur, il est recommandé.
• Pas l'implicit grant. Il renvoie les jetons dans la redirection du navigateur, où ils peuvent fuiter ; les clients ne devraient pas l'utiliser.
• Pas le resource owner password credentials grant. Confier le mot de passe de l'utilisateur au client va à l'encontre du but ; la BCP dit qu'il ne doit pas être utilisé.
• Client credentials pour les appels de service à service, sans utilisateur.

Le brouillon d'OAuth 2.1 réunit ces règles dans un seul document, si bien que les nouvelles bibliothèques les supposent de plus en plus.

PKCE en un paragraphe

Proof Key for Code Exchange, la RFC 7636, protège l'authorization code. Avant la redirection, le client crée un code_verifier aléatoire (de 43 à 128 caractères) et n'envoie que son hachage SHA-256, le code_challenge, avec code_challenge_method=S256. Quand le client échange ensuite le code contre des jetons, il envoie le verifier. Le serveur le hache et compare. Un attaquant qui intercepte le code ne peut pas l'utiliser sans le verifier, qui n'a jamais quitté le client.

Le flux, étape par étape

1. L'utilisateur clique sur Se connecter. Le client génère state (une valeur aléatoire liée à la session de l'utilisateur) ainsi que le verifier et le challenge PKCE.
2. Le client redirige vers /authorize avec response_type=code, client_id, la redirect_uri enregistrée, le scope demandé, state et le code challenge.
3. Le serveur d'autorisation affiche sa page de connexion et de consentement. Le client n'intervient pas ; cela se passe sur le domaine du serveur.
4. L'utilisateur se connecte, complète la MFA si nécessaire et consent aux scopes.
5. Le serveur redirige vers la redirect_uri enregistrée exacte, avec un code à usage unique et de courte durée, et le même state. Le client vérifie que state correspond à ce qu'il a envoyé ; sinon, il s'arrête. La RFC 6749 recommande une durée de vie du code de 10 minutes au maximum.
6. Le client envoie un POST à /token avec le code, l'URI de redirection et le code_verifier (plus son authentification client s'il s'agit d'un client confidentiel). C'est une requête en back channel, pas une redirection.
7. Le serveur renvoie les jetons : un access token, généralement un refresh token, et un ID token si vous utilisez OpenID Connect.
8. Le client appelle l'API avec Authorization: Bearer <access token>.
9. L'API valide le jeton et répond. Pour des access tokens JWT, elle vérifie localement la signature, l'émetteur, l'audience, l'expiration et les scopes ; pour des jetons opaques, elle interroge l'endpoint d'introspection du serveur d'autorisation.
10. Quand l'access token expire, le client envoie le refresh token en POST à /token.
11. Le serveur renvoie un nouvel access token, et pour les clients publics un nouveau refresh token. La RFC 9700 exige que les refresh tokens des clients publics soient liés à l'émetteur ou renouvelés à chaque usage, pour qu'un refresh token volé cesse de fonctionner après une utilisation par l'une ou l'autre partie.

Le diagramme de séquence

Comment le lire :

• Quatre lignes de vie, de gauche à droite : l'utilisateur, l'application cliente, le serveur d'autorisation et l'API.
• Les flèches pleines à pointe pleine sont des requêtes ; les flèches pointillées sont des réponses et des redirections de retour.
• Les étapes 2 à 5 sont des redirections en front channel par le navigateur ; l'étape 6 est la requête de jeton en back channel, là où PKCE fait la différence.
• Le fragment opt en bas ne s'exécute que quand l'access token a expiré.
• Le bloc Markdown liste les contrôles de chaque partie, là où se cachent la plupart des vrais bugs.

Les erreurs qui reviennent en revue

• Ne pas vérifier state. Sans ce contrôle, un attaquant peut terminer un flux de connexion dans le navigateur de la victime avec le compte de l'attaquant.
• Une comparaison laxiste de l'URI de redirection. Le serveur doit comparer exactement avec l'URI enregistrée ; une correspondance par préfixe ou joker permet de voler des codes.
• Des jetons dans le local storage d'une single-page app. N'importe quelle injection de script peut les lire. Beaucoup d'équipes placent un petit backend devant la SPA (un backend-for-frontend) qui garde les jetons et donne au navigateur un cookie de session.
• Des API qui acceptent n'importe quel jeton valide. Vérifiez l'audience, sinon un jeton émis pour une autre API fonctionnera sur la vôtre.
• Des web views intégrées dans les applications mobiles. La RFC 8252 indique que les applications natives devraient utiliser le navigateur du système, pour que l'application ne puisse pas voir les identifiants de l'utilisateur.
• Des access tokens de longue durée pour éviter la logique de refresh. Gardez des access tokens courts et rafraîchissez-les ; une révocation prend alors effet rapidement.

Ce qu'il faut dessiner sur un diagramme OAuth

• Chaque partie sur sa propre ligne de vie, y compris le navigateur si votre client a un backend.
• Le front channel et le back channel distingués, car leurs propriétés de sécurité diffèrent.
• Les noms des paramètres sur les flèches : state, code_challenge, code, code_verifier. Les relecteurs les cherchent.
• Qui valide quoi. Les contrôles sont la conception ; les flèches ne font que déplacer des données.

Si vous dessinez le paysage de sécurité plus large, le diagramme d'architecture zero trust montre où se place le fournisseur d'identité parmi les autres contrôles, et le diagramme d'architecture d'une passerelle API traite la validation des jetons une seule fois en bordure. L'exemple de diagramme de séquence explique plus en détail la notation utilisée ici.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Depuis le pack Séquence, ajoutez un Acteur pour l'utilisateur et trois nœuds Ligne de vie pour l'application cliente, le serveur d'autorisation et l'API, alignés et de même hauteur.
3. Dessinez chaque message comme une arête droite entre les lignes de vie, de haut en bas, avec les noms des paramètres dans l'étiquette. Utilisez des arêtes pointillées à pointe ouverte pour les réponses et les redirections.
4. Ajoutez un Fragment combiné avec l'opérateur opt autour des étapes de refresh.
5. Ajoutez un bloc Markdown du pack Base avec les contrôles de chaque partie.

L'exemple utilise 6 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Quelle différence entre OAuth 2.0 et OpenID Connect ? OAuth 2.0 concerne l'accès délégué : le client obtient un jeton pour appeler une API. OpenID Connect ajoute l'identité par-dessus : un ID token qui dit au client qui est l'utilisateur, et un endpoint standard d'informations utilisateur.

Faut-il PKCE si mon application a un client secret ? La RFC 9700 le recommande aussi pour les clients confidentiels. Il protège contre l'injection de code et ne coûte qu'un paramètre de plus de chaque côté.

Faut-il encore utiliser l'implicit grant ? Non. Les bonnes pratiques actuelles disent que les clients ne devraient pas l'utiliser. Utilisez à la place l'authorization code grant avec PKCE, y compris dans les single-page apps.

Où une single-page app doit-elle stocker les jetons ? De préférence pas du tout dans le navigateur : un backend-for-frontend peut garder les jetons côté serveur et donner au navigateur un cookie de session sécurisé. Si les jetons doivent vivre dans le navigateur, gardez-les en mémoire, gardez des access tokens courts et utilisez la rotation des refresh tokens.

Comment l'API valide-t-elle un access token ? Pour des access tokens JWT, en vérifiant la signature avec les clés publiées par le serveur d'autorisation, ainsi que l'émetteur, l'audience, l'expiration et le scope. Pour des jetons opaques, en appelant l'endpoint d'introspection.

Commencez gratuitement — un siège, sans carte bancaire.