PKCE : sécuriser les clients publics

Sans PKCE, les applications mobiles sont vulnérables aux attaques par interception du code d'autorisation. Lorsque le serveur d'autorisation redirige le code d'autorisation vers le schéma d'URI personnalisé enregistré par l'application (par exemple, myapp://callback), toute application malveillante présente sur le même appareil et enregistrant le même schéma d'URI peut intercepter la redirection et dérober le code.

L'attaque se déroule ainsi : une application malveillante enregistre le même schéma d'URI personnalisé que l'application légitime. Lorsque le serveur d'autorisation redirige le code vers myapp://callback, l'OS peut proposer les deux applications comme gestionnaires. Si l'utilisateur sélectionne l'application malveillante ou si l'OS la choisit par défaut, l'attaquant reçoit le code d'autorisation et peut l'échanger contre des jetons sans connaître le secret du client.

PKCE (RFC 7636) ajoute un secret généré dynamiquement au flux de code d'autorisation. Avant de lancer le flux, le client génère une chaîne aléatoire cryptographiquement sûre de 43 à 128 caractères, appelée vérificateur de code. Cette chaîne est propre à chaque demande d'autorisation et n'est jamais transmise avant l'étape d'échange des jetons.

Le client calcule un défi de code à partir du vérificateur : code_challenge = BASE64URL(SHA256(code_verifier)). L'utilisation de SHA256 est la méthode requise par la RFC 7636 (la méthode "plain", qui envoie directement le vérificateur, n'est pas recommandée). Le défi de code est une transformation à sens unique du vérificateur : connaître le défi ne permet donc pas de retrouver le vérificateur.

La demande d'autorisation inclut deux paramètres supplémentaires : "code_challenge=BASE64URL(SHA256(verifier))&code_challenge_method=S256". Le serveur d'autorisation enregistre le défi de code associé au code d'autorisation émis. Aucun secret susceptible d'être intercepté à ce stade n'est transmis au serveur.

Lors de l'échange des jetons (POST vers le point de terminaison des jetons), le client inclut "code_verifier=ORIGINAL_RANDOM_STRING" avec le code d'autorisation. Le serveur d'autorisation calcule BASE64URL(SHA256(code_verifier)) et vérifie que le résultat correspond au code_challenge enregistré. Seul le client légitime ayant généré le vérificateur peut réussir cette vérification.

Si un attaquant intercepte le code d'autorisation, il ne reçoit que le code et le défi de code, qui est public. Pour échanger le code contre des jetons, il doit fournir le vérificateur de code. Comme le vérificateur a été généré par le client légitime et n'a jamais été transmis avant l'échange des jetons, qui s'effectue de manière sécurisée, l'attaquant ne peut ni le calculer ni le récupérer.

PKCE empêche également les attaques par injection de code d'autorisation, lors desquelles un attaquant remplace un code valide par un code volé dans la redirection. Le défi associé au code volé ne correspond pas au vérificateur que le client de la victime présentera, ce qui fait échouer l'échange de jetons. PKCE fournit une défense en profondeur contre plusieurs vecteurs d'attaque simultanément.

Bien que la RFC 7636 ait initialement présenté PKCE comme une solution pour les clients publics (ceux qui ne possèdent pas de secrets client), le BCP de sécurité OAuth et OAuth 2.1 exigent PKCE pour tous les clients, y compris les clients confidentiels possédant des secrets client. PKCE fournit une protection indépendante de l'authentification du client, ce qui la rend universellement utile.

OAuth 2.1 (draft-ietf-oauth-v2-1) regroupe les bonnes pratiques de sécurité du BCP de sécurité OAuth 2.0 dans un document unique. Il impose PKCE pour tous les flux de code d'autorisation, rend le flux implicite obsolète et exige la rotation des jetons d'actualisation. PKCE constitue de fait la base obligatoire de toute nouvelle implémentation OAuth 2.0.

Implémenter PKCE correctement exige : d'utiliser un générateur aléatoire sécurisé du point de vue cryptographique pour le vérificateur (au moins 32 octets aléatoires, puis encodés en base64url), de stocker le vérificateur de manière sécurisée dans le client (et non dans l'URL ou les journaux), d'utiliser la méthode S256 (et non plain) et de veiller à supprimer le vérificateur après l'échange de jetons. La plupart des bibliothèques OAuth modernes gèrent automatiquement PKCE.

PKCE (RFC 7636) empêche l'interception du code d'autorisation en liant chaque code à un vérificateur de code généré dynamiquement, connu uniquement du client légitime. Le vérificateur est haché pour produire le défi associé au code (envoyé publiquement). L'échange de jetons exige le vérificateur d'origine. PKCE empêche à la fois les attaques par interception et par injection. OAuth 2.1 impose PKCE pour tous les flux de code d'autorisation.