PKCE : Proof Key for Code Exchange
Sécurité
PKCE : Proof Key for Code Exchange. « Preuve de possession pour l'échange du code », extension d'OAuth (RFC 7636) qui lie le code d'autorisation au client qui a lancé le flux, par analogie avec le ticket de vestiaire déchiré en deux : sans la moitié restée dans votre poche, le manteau ne sort pas.
Mécanisme : Le client tire une valeur secrète aléatoire, le code_verifier, et n'envoie au départ que son empreinte, le code_challenge, calculée par SHA-256 (méthode S256). Au moment d'échanger le code contre un jeton, il présente le code_verifier ; le serveur recalcule l'empreinte et refuse si elle ne correspond pas.
Contre quoi : Il neutralise l'interception du code d'autorisation : redirection mal validée, application malveillante enregistrée sur le même schéma d'URL sur mobile, journaux qui conservent l'adresse de retour. Le code volé est inutilisable sans le code_verifier, qui n'a jamais quitté le client.
Pour qui : Conçu pour les clients publics, incapables de garder un secret (applications mobiles, de bureau, pages exécutées dans le navigateur), il est désormais recommandé pour tous les clients, confidentiels compris. OAuth 2.1 l'impose au flux du code d'autorisation. La méthode plain, qui envoie le secret tel quel, ne doit plus être acceptée.
Ce qu'il ne fait pas : PKCE ne protège ni un navigateur compromis, ni une redirection permissive, ni un jeton déjà volé. Il protège l'échange d'un code intercepté, et c'est déjà beaucoup pour quarante-trois caractères aléatoires.
Ce qui arrive si on s'en passe
Sans PKCE, le code d'autorisation suffit à obtenir un jeton : quiconque l'intercepte peut l'échanger à la place du client légitime. Sur mobile, une application malveillante qui déclare le même schéma de redirection reçoit le code ; dans un navigateur, une redirection ouverte ou un journal qui conserve l'adresse de retour le laisse fuiter. Un client public n'ayant pas de secret à présenter, rien ne distingue alors l'attaquant de l'application. L'attaquant obtient un jeton d'accès, parfois un jeton de rafraîchissement, et agit au nom de l'utilisateur sans jamais connaître son mot de passe. Imposer PKCE avec la méthode S256 côté serveur d'autorisation, pour tous les clients, ferme cette voie.
Explication de la marmotte
Quand tu te connectes à une application avec ton compte d'un autre service, ce service renvoie un petit code à l'application pour dire « c'est bon ». Si quelqu'un vole ce code en chemin, il pourrait l'utiliser à la place de l'application. Pour l'éviter, l'application choisit d'abord un secret, en montre seulement une empreinte au départ, puis présente le vrai secret à la fin. Le voleur a le code, mais pas le secret : le service refuse. C'est comme un ticket de vestiaire dont tu gardes une moitié.
Où ce terme est utilisé
- Pièges OAuth 2.1 : PKCE, redirections et scopes (12 occurrences)
- Le flux OAuth avec PKCE en une page (11 occurrences)
- Configurer OIDC entre Keycloak et application interne (5 occurrences)
- OIDC, SAML et OAuth 2.1 en fédération (3 occurrences)
- Attaque par confusion de scope OAuth (2 occurrences)