Créer la clé d’API d’un service
Générez une clé de 32 octets en Base64URL avec un préfixe du type myapp_live_, remettez-la au client une seule fois et ne conservez côté serveur que son empreinte SHA-256.
Créez jusqu’à 20 jetons aléatoires à la fois pour clés d’API, secrets de webhook ou jetons de session, en hex, Base64 ou Base64URL, avec préfixe comme sk_live_ et entropie affichée. Généré localement.
Ce générateur produit des jetons aléatoires cryptographiquement sûrs de 8 à 256 octets, jusqu’à 20 à la fois, en hexadécimal, Base64 ou Base64URL. Il sert aux développeurs et administrateurs qui ont besoin d’une clé d’API, d’un secret de webhook, d’un jeton de réinitialisation ou d’une clé de signature, sans passer par un terminal.
Les octets sont tirés par crypto.getRandomValues, le générateur aléatoire cryptographique du navigateur alimenté par le système d’exploitation, et non par Math.random, qui est prévisible. L’entropie affichée vaut simplement le nombre d’octets multiplié par 8 : les 32 octets par défaut donnent 256 bits, soit 2^256 valeurs possibles, bien au-delà de ce qu’une attaque par force brute peut parcourir. Pour un jeton d’authentification, 128 bits (16 octets) sont un plancher raisonnable et 256 bits un choix confortable pour une clé d’API ou un secret HMAC.
L’encodage ne change pas la sécurité, seulement la longueur et les caractères utilisés. Les mêmes 32 octets donnent 64 caractères en hexadécimal, 44 en Base64 avec le « = » final, et 43 en Base64URL (RFC 4648, section 5), qui remplace « + » et « / » par « - » et « _ » et supprime le remplissage pour pouvoir figurer tel quel dans une URL, un en-tête HTTP ou un nom de fichier. Le préfixe optionnel, par exemple sk_live_, est ajouté devant le jeton sans compter dans l’entropie : il permet d’identifier le type de clé d’un coup d’œil et aide les scanners de secrets, comme celui de GitHub, à repérer une fuite.
Choisissez le nombre d’octets (8 à 256, 32 par défaut) et le format de sortie : hexadécimal, Base64 ou Base64URL. L’entropie correspondante en bits s’affiche.
Saisissez si besoin un préfixe comme sk_live_ et indiquez combien de jetons générer, de 1 à 20.
Lancez la génération : chaque jeton apparaît dans la liste, prêt à être copié dans votre configuration ou votre gestionnaire de secrets.
Générez une clé de 32 octets en Base64URL avec un préfixe du type myapp_live_, remettez-la au client une seule fois et ne conservez côté serveur que son empreinte SHA-256.
GitHub, Stripe ou Shopify signent leurs webhooks avec un secret partagé : générez-en un en hexadécimal, collez-le dans la configuration du service et dans votre application pour vérifier la signature HMAC.
Générez d’un coup plusieurs valeurs pour SESSION_SECRET, APP_KEY ou JWT_SECRET afin d’initialiser un environnement de développement ou de préproduction avec des secrets distincts.
Visez au moins 128 bits d’entropie, soit 16 octets, et de préférence 256 bits, soit 32 octets, la valeur par défaut. Cela donne 43 caractères en Base64URL ou 64 en hexadécimal. Au-delà, le gain de sécurité est négligeable et la clé devient seulement plus encombrante.
Les trois représentent les mêmes octets et offrent la même sécurité. L’hexadécimal est le plus lisible et le plus compatible, Base64 est plus compact, et Base64URL est aussi compact tout en restant sûr dans les URL, les en-têtes et les noms de fichier. Suivez le format attendu par le service ou la bibliothèque qui consommera le jeton.
Oui, c’est le générateur aléatoire cryptographique exposé par l’API Web Crypto, alimenté par le système d’exploitation, comme /dev/urandom ou os.urandom. Il convient à la génération de clés et de jetons. Math.random, au contraire, n’est pas conçu pour la sécurité et ses sorties peuvent être prédites.
Un préfixe indique la nature d’une clé, par exemple secrète ou publique, production ou test, sans révéler sa valeur. Il facilite le support et permet aux outils de détection de secrets de reconnaître une clé exposée dans un dépôt Git. Stripe (sk_live_) et GitHub (ghp_) l’utilisent pour cette raison.
Un UUID v4 ne contient que 122 bits aléatoires et sert avant tout d’identifiant unique ; certaines versions, comme v1 ou v7, contiennent même un horodatage prévisible. Pour un secret, un jeton de 32 octets tiré au hasard offre 256 bits d’entropie et ne révèle aucune information. Utilisez un UUID pour identifier, un jeton pour authentifier.
Non : ils sont produits dans votre navigateur et n’existent que sur la page tant que vous ne les copiez pas. Aucun jeton n’est transmis ni journalisé. Copiez-les directement dans votre gestionnaire de secrets et fermez la page une fois terminé.
Outils associés
Des outils similaires ou complémentaires à celui-ci.
Générez des mots de passe forts et aléatoires de 8 à 128 caractères, avec l’entropie affichée.
Générez un code_verifier PKCE, son code_challenge S256 et un state pour votre requête d’autorisation OAuth.
Calculez un HMAC SHA-1, SHA-256, SHA-384 ou SHA-512 en hex ou Base64 et vérifiez une signature de webhook.
Comprenez comment OAuth 2.0, PKCE, JWT, JWK et JWKS s’articulent sans les confondre : autorisation, jetons, clés publiques et vérification.
Comprenez comment RGB, HEX et HSL décrivent les couleurs sRGB afin de choisir une notation CSS lisible et de convertir les valeurs sans confusion.
Apprenez à construire une CSP progressive, comprendre ses directives et éviter les politiques trop permissives ou cassantes.
Découvrez comment empiler plusieurs tableaux compatibles, harmoniser leurs colonnes et distinguer l’assemblage vertical d’une jointure sur clé.