Le guide
Un « flow » (ou « grant ») est la façon dont une application obtient ses jetons. Il y en a plusieurs parce que les applications sont très différentes : un site web, une application mobile, un téléviseur, un service sans utilisateur… n’ont pas les mêmes contraintes ni les mêmes secrets à protéger.
Voir aussi : les flows en diagrammes de séquence · les fonctions avancées expliquées (PAR, JAR, JARM, DPoP, CIBA) · la frise de l’évolution d’OAuth et d’OpenID Connect
Tout le reste existe pour des raisons historiques ou des besoins précis. Refresh Token n’est pas un flow de connexion : c’est un complément pour garder la session.
OAuth 2.0 (2012) a dû servir à la fois des serveurs capables de garder un secret et des applications dans un navigateur qui ne le peuvent pas. D’où l’implicit pour les SPA, le password pour les applications « de confiance », et le code pour les serveurs. Avec les années, on a constaté que les jetons dans l’URL fuyaient (implicit) et que donner son mot de passe à l’application annulait tout l’intérêt (password). OAuth 2.1 et les recommandations de sécurité actuelles ont donc tout ramené au code + PKCE, en gardant client credentials et device pour leurs cas propres. OIDC a ajouté le flow hybride pour obtenir l’identité tout de suite.
À utiliser quand : une personne se connecte à un site web (avec ou sans serveur), une SPA, une application mobile ou de bureau. Avec un serveur capable de garder un secret, ajoutez le client_secret ; sans (SPA, mobile), PKCE suffit.
Pourquoi il existe : le navigateur ne reçoit qu’un code à usage unique et de courte durée ; les jetons, eux, passent directement du serveur de l’application à l’OP (« canal arrière »). PKCE lie le code à celui qui l’a demandé, ce qui empêche qu’un code intercepté serve à quelqu’un d’autre.
Les pièges : oublier PKCE (aujourd’hui exigé même pour les clients confidentiels), ne pas vérifier state et nonce, accepter des redirect_uri trop larges, jetons dans localStorage pour une SPA.
Déroulé :
code_verifier (secret aléatoire), state, nonce, et calcule code_challenge = SHA-256(code_verifier)./authorize?response_type=code&code_challenge=…&state=…&nonce=….redirect_uri?code=…&state=…./token avec le code et le code_verifier (et son secret si elle en a un).iss, aud, nonce.À utiliser quand : l’application a besoin de l’identité immédiatement (avant l’échange du code), par exemple pour une validation de session côté serveur ou parce qu’une ancienne bibliothèque (ASP.NET, Java EE) le configure par défaut.
Pourquoi il existe : OIDC a voulu permettre de lire l’identité tout de suite tout en gardant le code pour obtenir les jetons de manière sûre. Le c_hash et at_hash de l’ID token lient le code et l’access token à cette identité.
Les pièges : jetons dans le fragment de l’URL (visibles de l’historique et des scripts), c_hash/at_hash non vérifiés, et un nonce obligatoire oublié. Préférez le code seul si rien ne vous y oblige.
Déroulé :
/authorize?response_type=code id_token&nonce=… (ou code token, code id_token token).#code=…&id_token=…&state=… dans le fragment (response_mode=fragment par défaut) ou en POST (form_post).c_hash.À utiliser quand : presque jamais pour du neuf. Vous le rencontrez dans de vieilles SPA, ou pour vérifier qu’une application l’interdit bien.
Pourquoi il existe : avant que les navigateurs gèrent les appels croisés (CORS) et PKCE, une SPA ne pouvait pas appeler /token ; on lui donnait donc les jetons directement.
Les pièges : le jeton circule dans l’URL : historique, journaux de proxy, en-tête Referer, extensions. Aucun refresh token, aucune liaison à l’appelant. Retiré d’OAuth 2.1.
Déroulé :
/authorize?response_type=id_token token&nonce=….#id_token=…&access_token=…&state=….À utiliser quand : un service, un traitement planifié ou un démon appelle une API en son nom propre : synchronisation, tâche de nuit, microservices entre eux.
Pourquoi il existe : beaucoup d’appels d’API n’ont aucune personne derrière. Le client prouve son identité (secret, ou mieux : assertion signée) et reçoit un access token limité à ses scopes.
Les pièges : pas d’ID token ni de refresh token (c’est normal). Ne mettez jamais ce secret dans une application distribuée (mobile, SPA). Donnez le strict minimum de scopes et faites tourner le secret.
Déroulé :
POST /token avec grant_type=client_credentials, scope=… et l’authentification du client (secret Basic ou dans le corps).Authorization: Bearer ….À utiliser quand : vous voulez des access tokens de courte durée (quelques minutes) tout en gardant la personne connectée longtemps. Se demande avec le scope offline_access.
Pourquoi il existe : plus un jeton vit longtemps, plus son vol est grave. Le refresh token reste côté application, loin des API, et ne sert qu’à renouveler.
Les pièges : refresh token volé = accès prolongé : stockage sûr, rotation (un nouveau à chaque usage, l’ancien devient invalide) et détection de réutilisation.
Déroulé :
POST /token avec grant_type=refresh_token&refresh_token=….À utiliser quand : télévision, console, objet connecté, imprimante, outil en ligne de commande : l’appareil n’a pas de navigateur ou de clavier pratique.
Pourquoi il existe : saisir un mot de passe avec une télécommande est pénible et risqué. On affiche un court code ; la personne le saisit sur son téléphone ou son ordinateur, où elle s’authentifie normalement.
Les pièges : code de courte durée et à usage unique, pas de sondage trop rapide (slow_down), et limitation des essais pour éviter qu’on devine un code. Hameçonnage possible : affichez bien ce que la personne autorise.
Déroulé :
/device_authorization et reçoit device_code, user_code et l’adresse de vérification./token avec le device_code. D’abord authorization_pending, puis les jetons.À utiliser quand : à éviter. Parfois toléré pour une migration depuis un ancien système ou des tests automatisés dans un environnement contrôlé.
Pourquoi il existe : une transition pour les applications qui collectaient déjà des mots de passe, sans changer leur interface.
Les pièges : l’application voit le mot de passe : exactement ce que l’OIDC cherche à éviter. Pas d’authentification multifacteur, pas de SSO, hameçonnage facilité. Retiré d’OAuth 2.1.
Déroulé :
POST /token avec grant_type=password&username=…&password=….Tous les détails en images : diagrammes de séquence.
Tester chaque flow. Le fournisseur de test d’ID-Kit sait jouer tous ces flows, avec des erreurs simulées ; l’application de test les déroule contre votre vrai fournisseur.