Le flux OAuth avec PKCE en une page

OAuth confie un code précieux au navigateur, cet endroit où cohabitent quarante onglets, onze extensions et une confiance aveugle ; PKCE part du principe, assez sain, que ce code finira un jour dans de mauvaises mains, et s’arrange pour qu’il n’y serve à rien.

L’essentiel

Le navigateur ne porte qu’un code. Dans le flux du code d’autorisation (RFC 6749), le navigateur ne voit passer qu’un code éphémère ; l’application l’échange contre les jetons par un appel direct au point /token. La RFC recommande une durée de vie de dix minutes au plus et interdit de s’en servir deux fois.
Le maillon faible, c’est le retour. Sur un téléphone, un schéma d’URL personnalisé peut être revendiqué par deux applications (RFC 8252) ; ailleurs, le code traîne dans un journal, un historique ou une redirection trop permissive. On doit supposer qu’il fuit.
PKCE (RFC 7636) en trois gestes. L’application tire un code_verifier aléatoire de 43 à 128 caractères ; elle envoie à /authorize son empreinte, code_challenge = BASE64URL(SHA-256(code_verifier)), avec code_challenge_method=S256 ; à l’échange, elle présente le code_verifier, que le serveur hache et compare. Pas de correspondance : invalid_grant.
Un secret neuf à chaque connexion. Le vérificateur ne quitte l’application qu’au moment de l’échange, sous TLS, directement vers le serveur. L’empreinte, elle, peut se montrer : SHA-256 ne se remonte pas.
C’est désormais la règle. La RFC 9700 (bonnes pratiques de sécurité OAuth 2.0, janvier 2025) impose PKCE aux clients publics, le recommande aux clients confidentiels, écarte le flux implicite et le flux par mot de passe, et exige une comparaison exacte des adresses de retour.
OAuth délègue, OpenID Connect identifie. Le jeton d’accès dit ce qu’un client peut faire ; qui est connecté, c’est le jeton d’identité d’OIDC, délivré par le même échange.
PKCE protège un échange, pas tout le reste. Un jeton d’accès volé après délivrance, un navigateur compromis, des scopes trop larges ou un jeton accepté par la mauvaise API restent entiers.

« Un client_secret dans l’appli fait aussi bien. » Faux. Un secret livré à des milliers d’exemplaires dans un binaire téléchargeable n’est plus un secret, c’est une citation. PKCE fabrique un secret par connexion, que personne n’a jamais pu télécharger.
« La méthode plain suffit. » Faux. Avec plain, le challenge est le vérificateur : il part en clair dès la première redirection, là précisément où l’on craignait l’indiscrétion. C’est confier la clé du coffre au coursier en lui demandant de ne pas regarder.
« Avec PKCE, plus besoin de soigner l’adresse de retour. » Faux. PKCE empêche d’échanger un code volé, pas de le voler. La comparaison exacte de redirect_uri reste exigée, et une redirection ouverte reste une redirection ouverte.
« PKCE, c’est pour les applis mobiles. » Faux. C’est là qu’il est né. La RFC 9700 le recommande aussi aux applications serveur, parce qu’il bloque en plus l’injection d’un code volé dans la session de quelqu’un d’autre.
« OAuth, c’est pour se connecter. » Faux. OAuth remet un droit d’accès à une application, pas un certificat d’identité à une personne. Ouvrir une session sur la foi d’un jeton d’accès, c’est accueillir quelqu’un parce qu’il a les clés de la cave.

Pour aller plus loin : Pièges OAuth 2.1 : PKCE, redirections et scopes · OIDC, SAML et OAuth 2.1 en fédération · Gérer la durée de vie des jetons OAuth · Configurer OIDC entre Keycloak et application interne · Attaque par confusion de scope OAuth · Connecteurs OAuth des assistants IA, portée et consentements.

Pages voisines

Le flux OAuth avec PKCE en une page

Elle cite

Le flux OAuth avec PKCE en une page

L’essentiel

À lire aussi

Pages voisines