Aller au contenu principal
Bethemesh
Sécurité & confidentialité

Générateur OAuth PKCE

Créez un code_verifier aléatoire de 43 à 128 caractères et son code_challenge S256 (RFC 7636), ou calculez le challenge d’un verifier existant, avec un state aléatoire et les paramètres à ajouter à la requête d’autorisation.

  • Presse-papiers

Intégrer ce widget

Personnalisez le rendu, vérifiez l’aperçu puis copiez le code.

Aperçu

Type de code d’intégration

Code à copier

Responsive et redimensionné automatiquement par Bethemesh.

Laissez vide pour en générer un, ou collez un verifier existant pour calculer son challenge.

Valeurs PKCE

À garder côté client et à envoyer lors de l’échange du code contre un jeton.

Base64URL du SHA-256 du verifier, à envoyer dans la demande d’autorisation.

Valeur aléatoire à vérifier au retour pour bloquer les attaques CSRF.

Cet outil vous a-t-il été utile ?

Comment fonctionne cet outil ?

Le générateur OAuth PKCE produit la paire code_verifier / code_challenge exigée par le flux Authorization Code avec PKCE, ainsi qu’un paramètre state. Il sert aux développeurs qui intègrent une connexion OAuth 2.0 ou OpenID Connect dans une SPA, une application mobile ou un outil en ligne de commande, et à ceux qui testent le flux à la main avec curl ou Postman.

PKCE (Proof Key for Code Exchange, RFC 7636) protège le code d’autorisation contre l’interception. Le client crée un code_verifier secret de 43 à 128 caractères tirés de l’ensemble non réservé A–Z, a–z, 0–9, « - », « . », « _ » et « ~ » ; l’outil en génère 64 par défaut avec crypto.getRandomValues. Il calcule ensuite code_challenge = BASE64URL(SHA-256(code_verifier)), sans remplissage. Avec l’exemple de l’annexe B de la RFC, le verifier dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk donne le challenge E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM.

Le challenge part dans la requête d’autorisation avec code_challenge_method=S256 et un state aléatoire ; le verifier reste chez le client. Lors de l’échange du code contre un jeton, le client envoie code_verifier au point de terminaison token, et le serveur recalcule le SHA-256 pour vérifier qu’il correspond au challenge reçu. Un attaquant qui intercepte le code ne peut donc pas l’échanger sans le verifier. L’outil affiche les paramètres code_challenge, code_challenge_method et state à ajouter à l’URL d’autorisation, et peut aussi recalculer le challenge d’un verifier que vous collez pour vérifier votre propre implémentation.

Comment utiliser cet outil ?

  1. Générez ou collez un verifier

    Choisissez une longueur de 43 à 128 caractères (64 par défaut) pour générer un code_verifier, ou collez un verifier existant pour en calculer le challenge.

  2. Récupérez le challenge et le state

    Copiez le code_challenge S256 et le state aléatoire produits, en vérifiant la longueur affichée du verifier et du challenge (43 caractères pour un SHA-256).

  3. Complétez la requête d’autorisation

    Ajoutez code_challenge, code_challenge_method=S256 et state à l’URL d’autorisation, puis conservez le verifier pour l’envoyer lors de l’échange du code.

Cas d'utilisation

Tester un flux OAuth à la main

Construisez une URL d’autorisation pour Google, Microsoft Entra ID, Okta ou Keycloak, connectez-vous dans le navigateur, puis échangez le code avec curl en envoyant le code_verifier généré.

Déboguer une erreur invalid_grant

Votre serveur renvoie « PKCE verification failed » : collez le verifier utilisé par votre application pour vérifier que le challenge qu’elle envoie est bien le Base64URL du SHA-256, sans = ni caractères + et /.

Configurer un client Postman ou Insomnia

Générez une paire verifier / challenge et un state pour renseigner manuellement un client HTTP qui ne gère pas PKCE automatiquement.

Conseils et bonnes pratiques

  • Générez un nouveau verifier et un nouveau state pour chaque tentative de connexion : réutiliser une paire fixe annule l’intérêt de PKCE.
  • N’utilisez pas la méthode plain : la RFC 7636 réserve plain aux clients incapables de calculer SHA-256, ce qui n’est plus le cas d’aucun navigateur ni mobile actuel.
  • Dans une SPA, stockez le verifier en sessionStorage le temps de la redirection plutôt que dans le stockage persistant du navigateur, et supprimez-le dès que le code a été échangé.

Questions fréquentes

Qu’est-ce que PKCE en OAuth ?

PKCE (RFC 7636) est une extension du flux Authorization Code : le client prouve, au moment d’échanger le code, qu’il est bien celui qui a lancé la demande. Il envoie d’abord un code_challenge dérivé d’un secret, puis le secret lui-même (code_verifier). Le code intercepté devient inutilisable sans ce secret.

Quelle longueur doit avoir le code_verifier ?

Entre 43 et 128 caractères, uniquement parmi A–Z, a–z, 0–9 et « - . _ ~ ». La RFC 7636 recommande de le produire à partir d’au moins 32 octets aléatoires, ce qui donne 43 caractères en Base64URL. Une valeur de 64 caractères offre une marge confortable.

Faut-il utiliser S256 ou plain ?

S256. Avec plain, le challenge est égal au verifier : quiconque voit la requête d’autorisation connaît aussi le secret. Les serveurs qui prennent en charge PKCE doivent accepter S256, et plain n’existe que pour des cas historiques.

Le paramètre state est-il encore nécessaire avec PKCE ?

La RFC 9700 admet que PKCE protège contre les attaques CSRF lorsque le serveur l’applique réellement, mais state reste recommandé pour relier la réponse à la session de l’utilisateur et transporter un contexte applicatif. De nombreux fournisseurs l’exigent encore. L’outil génère donc les deux.

PKCE est-il obligatoire pour les clients confidentiels ?

La RFC 9700 (bonnes pratiques de sécurité OAuth 2.0, 2025) impose PKCE aux clients publics et le recommande pour les clients confidentiels ; le projet OAuth 2.1 le rend obligatoire pour tout client utilisant le code d’autorisation. En pratique, activez-le partout, y compris pour une application serveur avec client_secret.

Pourquoi mon code_challenge est-il refusé ?

Les erreurs classiques sont un challenge encodé en Base64 standard (avec +, / ou =) au lieu de Base64URL, un hash calculé sur une version hexadécimale du SHA-256, ou un verifier différent entre la requête d’autorisation et l’échange du code. Collez votre verifier dans l’outil pour comparer le challenge attendu, calculé localement sans envoi réseau.

Outils associés

Continuez avec ces outils

Des outils similaires ou complémentaires à celui-ci.

Fonctionne bien avec

Générateur de jetons sécurisés

Générez des jetons aléatoires sûrs de 8 à 256 octets en hexadécimal, Base64 ou Base64URL, avec préfixe optionnel.

Sécurité & confidentialitéNouveauUtiliser l’outil

Inspecteur JWK / JWKS

Analysez une clé JWK ou un JWKS : kid, kty, alg, use, empreinte RFC 7638 et alerte si une clé privée est exposée.

Sécurité & confidentialitéNouveauUtiliser l’outil

Vérificateur de signature JWT

Vérifiez la signature d’un JWT avec un secret HMAC ou une clé publique JWK, JWKS ou PEM, puis contrôlez exp, nbf, iss et aud.

Sécurité & confidentialitéUtiliser l’outil

À lire aussi