search

Found

info Aperçu

Génère le code_verifier PKCE et son code_challenge S256 (RFC 7636) pour OAuth 2.0. Choisissez 43 à 128 caractères et copiez les snippets /authorize et /token.

📘 Mode d'emploi

  1. Choisissez la longueur du verifier entre 43 et 128 caractères avec le curseur
  2. Cliquez sur Régénérer pour obtenir un nouveau code_verifier et son code_challenge S256
  3. Consultez l'exemple de requête pour voir où placer chaque valeur dans /authorize et /token

Générateur de code_verifier PKCE

Copié !
Copié !

        

          
          
Copié !

        

      

    

  




            


            
            

            

            
            

                

                    grid_view Similaires
                

                
            


        


        
        
    


    
    
    

        
        

            

            Article
            

        


        
        

            
Générateur de code_verifier PKCE | Paires de test pour le flux PKCE OAuth 2.0


Générez une paire code_verifier et code_challenge au format S256 conforme à la RFC 7636 directement dans votre navigateur, avec une longueur de verifier comprise entre 43 et 128 caractères. La page produit également des exemples prêts à coller pour /authorize et /token, ce qui permet de les injecter dans Postman, curl ou votre client SPA, mobile ou CLI sans changer d'onglet.


💡 À propos de cet outil


PKCE est la parade officielle contre l'interception de l'authorization code pour les clients OAuth 2.0 publics — SPAs, applications mobiles, CLI natives et tout client incapable de stocker un client secret. La RFC 7636 impose au client de produire un code_verifier de forte entropie (43 à 128 caractères tirés de [A-Z][a-z][0-9]-._~), de calculer le code_challenge comme base64url(SHA-256(verifier)), puis d'envoyer le challenge à /authorize et le verifier d'origine à /token. Le calcul reste simple, mais le faire à la main à chaque test d'un serveur d'autorisation devient vite fastidieux.


L'outil s'appuie sur crypto.getRandomValues et crypto.subtle.digest('SHA-256') pour produire à chaque déplacement du curseur ou clic sur Régénérer une paire conforme, avec un encodage base64url complet (sans padding, +/ remplacés par -_). Le panneau du bas reproduit fidèlement les requêtes:


GET /authorize?response_type=code&client_id=YOUR_CLIENT_ID&code_challenge=...&code_challenge_method=S256&redirect_uri=...&state=RANDOM_STATE
POST /token (form): grant_type=authorization_code&code=...&code_verifier=...



Vous pouvez donc coller la même paire dans Auth0, Okta, Keycloak, AWS Cognito, Azure AD B2C, France Connect ou tout IdP interne basé sur OIDC. Aucune valeur n'est transmise à un serveur — l'outil convient donc aux tests de pré-production, aux exercices CTF et aux formations sécurité internes.


🧐 Questions fréquentes


Q. Quelle longueur de verifier choisir ?
A. Toute valeur entre 43 et 128 caractères est valide. Les bibliothèques courantes (Auth0 SPA SDK, MSAL.js, AppAuth, oidc-client-ts) prennent par défaut 43 à 64 caractères. Commencez à 64 — si votre serveur d'autorisation l'accepte, la longueur convient. Descendez à 43 pour limiter le volume de logs ou montez à 128 pour maximiser l'entropie dans un rapport d'audit.


Q. Pourquoi la méthode plain n'est-elle pas proposée ?
A. La RFC 7636 §4.2 marque S256 comme MUST-support et plain comme repli uniquement si le client ne peut pas calculer SHA-256. En 2026, tous les serveurs majeurs (Auth0, Okta, Google, Microsoft, GitHub, Spotify, Twitch, X) exigent S256, et le brouillon OAuth 2.1 supprime totalement plain. L'outil ne l'émet jamais pour éviter de câbler une paire fragile dans vos tests.


Q. L'outil fonctionne-t-il sur les vieux navigateurs sans SubtleCrypto ?
A. crypto.subtle.digest('SHA-256') est disponible sur tous les navigateurs evergreen (Chrome, Edge, Firefox, Safari) en contexte https:// ou localhost. L'outil fonctionne dans tout environnement de développement moderne mais échouera silencieusement sur IE 11 ou sur des pages servies en http:// hors localhost.


Q. Les valeurs générées sont-elles stockées quelque part ?
A. Non. Chaque mouvement du curseur ou clic sur Régénérer produit une nouvelle paire, sans stockage dans localStorage, cookies ou serveur. Traitez chaque paire comme jetable — recharger la page la remplace.


Q. Que mettre dans le paramètre state de l'exemple ?
A. state est votre protection CSRF — générez une chaîne aléatoire par session, stockez-la côté serveur ou dans un cookie sécurisé, puis vérifiez que le callback renvoie la même valeur. L'exemple laisse RANDOM_STATE en placeholder car state relève du client et ne fait pas partie de PKCE en soi.


📚 Le saviez-vous


PKCE a été publié en 2015 sous la référence RFC 7636, initialement présenté comme "extension pour applications natives" d'OAuth 2.0. Le brouillon OAuth 2.1 de 2019 l'a promu à "tous les clients, en permanence" et les principaux IdP ont suivi : Spotify a déprécié Implicit Grant en imposant PKCE sur la Web API en 2021, Twitch a fait de même avec l'API Helix et X (Twitter) l'a rendu obligatoire pour son OAuth 2.0 v2 en 2022. Le champ code_challenge_method accepte théoriquement toute valeur ajoutée par un serveur d'autorisation, mais en pratique seuls S256 et plain ont été standardisés — et plain quitte progressivement la spec. Un générateur moderne n'a donc qu'à produire S256 pour couvrir l'essentiel du web.