Mode d’emploi
- Cliquez sur Générer pour un nouveau code_verifier, ou collez le vôtre.
- Le code_challenge est calculé comme BASE64URL(SHA-256(code_verifier)).
- Envoyez code_challenge et code_challenge_method=S256 dans la requête d’autorisation.
- Envoyez le code_verifier dans la requête de jeton.
PKCE (Proof Key for Code Exchange, RFC 7636) protège le flux « authorization code » d’OAuth 2.0. Il a été conçu pour les clients publics, comme les applications mobiles, de bureau ou monopage, qui ne peuvent pas garder un secret client. Avant la redirection, le client crée un secret à usage unique, le code_verifier, et n’envoie que son empreinte, le code_challenge. Lors de l’échange du code contre des jetons, il envoie le verifier d’origine et le serveur vérifie la correspondance : intercepter le code seul ne suffit donc pas.
Ce générateur tire 32 octets aléatoires avec crypto.getRandomValues du navigateur et les encode en base64url sans remplissage, ce qui donne un verifier de 43 caractères. Le code_challenge est le SHA-256 du verifier, lui aussi en base64url sans remplissage, et fait toujours 43 caractères. Seule la méthode S256 est proposée : la RFC 7636 définit aussi plain, mais impose S256 dès que le client sait calculer un SHA-256. Pratique pour déboguer une intégration de connexion, comparer la sortie de votre bibliothèque ou préparer des requêtes de test.
Un verifier collé est haché tel quel, sans contrôle de format : vérifiez qu’il compte de 43 à 128 caractères parmi A–Z, a–z, 0–9, « - », « . », « _ » et « ~ ». Créez un nouveau verifier pour chaque demande d’autorisation. Les deux valeurs sont calculées sur cette page avec la Web Crypto API et ne sont envoyées nulle part.