Générateur de clés API

Comment utiliser le générateur de clés API

1. Choisissez le format, l’entropie visée et la quantité. Commencez par 256 bits et Base64URL, sauf exigence différente de votre application.
2. Ouvrez les options avancées pour les préfixes, alphabets ou identifiants publics. Vérifiez la longueur calculée avant la génération.
3. Générez les clés, puis copiez une valeur ou vérifiez l’export. Conservez les secrets de production dans votre gestionnaire de secrets, pas dans un document public.
4. Enregistrez le secret dans votre application. Configurez-y les accès, l’expiration et la révocation, puis effacez cette page lorsque vous avez terminé.

Pensé pour votre usage des secrets

Choisir, générer, copier : la tâche courante reste rapide. Pour les intégrations particulières, nous proposons aussi les encodages d’octets, alphabets personnalisés, étiquettes d’application, identifiants publics distincts et lots de 1 000 clés maximum. Aucun compte ni installation n’est nécessaire. Ces explications vous aident à choisir des réglages adaptés plutôt qu’à juger la solidité d’une clé à sa seule longueur apparente.

Des formats adaptés à votre application

Base64URL évite le plus et la barre oblique de Base64 classique et omet le remplissage. L’hexadécimal, facile à examiner et largement accepté, utilise davantage de caractères pour les mêmes octets. Base32 emploie ici A–Z et 2–7 sans remplissage. Base64 classique conserve son remplissage standard. Vérifiez les exigences de l’application destinataire : encoder n’est pas chiffrer.

Des alphabets personnalisés sans indications trompeuses

Choisissez des lettres, chiffres, un ensemble défini de symboles ou votre alphabet ASCII imprimable. Les caractères répétés sont dédupliqués pour ne pas favoriser leur apparition. L’exclusion des caractères similaires retire 0, O, 1, I, l et |. Un objectif en bits détermine la longueur nécessaire ; un nombre exact de caractères respecte la limite d’un champ. Un alphabet plus petit nécessite davantage de caractères pour atteindre la même entropie théorique.

Des points de départ, pas des identifiants de fournisseurs

Jeton API utilise Base64URL sur 256 bits. Secret de webhook utilise l’hexadécimal sur 256 bits pour votre propre système de vérification à secret partagé. Secret d’application utilise Base64URL sur 512 bits ; Lot de développement prépare dix jetons de 256 bits. Ce sont des raccourcis de configuration, pas des standards universels ni des clés émises par un fournisseur. Un préfixe ou suffixe repère l’application ou l’environnement. Le libellé live_ n’active rien et n’accorde aucun droit.

D’une clé unique à un export par lot propre

Copiez une clé ou tout le lot. Les paires facultatives ajoutent un identifiant public aléatoire de 96 bits pour retrouver un enregistrement ; gardez le secret privé et n’authentifiez pas avec l’ID. JSON préserve exactement les valeurs. TXT propose lignes, virgules ou espaces. CSV échappe les cellules et neutralise les débuts de formule, parfois avec une apostrophe. L’export .env valide les noms et refuse les guillemets incompatibles. Il vise les fichiers Node dotenv, pas les scripts shell. Les téléchargements sont des secrets en clair, pas des sauvegardes chiffrées.

Le calcul des bits, octets et caractères

Les formats d’octets utilisent ceil(bits visés / 8) octets aléatoires, soit octets × 8 bits nominaux. Pour N caractères indépendants et uniformes choisis parmi A caractères distincts, l’entropie théorique vaut N × log₂(A). Il faut donc ceil(bits visés / log₂(A)) caractères pour un objectif donné. Ainsi, 256 bits composés uniquement de chiffres nécessitent 78 chiffres, pas 32. Préfixes, suffixes et identifiant public séparé ne comptent pas dans l’entropie du secret. Ce calcul décrit la conception du générateur, sans mesurer ni certifier l’aléa du navigateur.

Une valeur aléatoire, plusieurs représentations

32 bytes × 8 = 256 bits

Ces longueurs excluent tout préfixe ou suffixe. L’encodage modifie la représentation, pas l’aléa sous-jacent.

Notre méthode de génération

Nous utilisons crypto.getRandomValues dans un contexte sécurisé. Aucun recours à Math.random, aux horodatages, à l’activité clavier ou à une graine prévisible. Les encodages d’octets conservent toutes les données. Pour les alphabets, l’échantillonnage par rejet écarte les valeurs du reste inégal avant de sélectionner un caractère. Il évite le biais d’un simple modulo lorsque la taille de l’alphabet ne divise pas 256. Chaque lot est contrôlé pour détecter les répétitions de secrets et d’identifiants. Le nombre d’essais est borné et un échec remplace tout résultat incomplet.

Ce qui reste dans votre navigateur

La génération et la préparation des exports sont locales. ClockTools n’envoie pas les valeurs générées à ses serveurs et ne les place ni dans les URL, ni dans les analyses, ni dans le stockage persistant. Même depuis un autre outil, cette page ouvre un nouveau document sans nos chargeurs d’analyse ou d’enregistrement de session. Les réglages enregistrés et partagés excluent les champs libres et les clés. L’hébergeur reçoit toujours les requêtes normales de page. Copier transfère la valeur au presse-papiers ; télécharger écrit un fichier en clair. Extensions, synchronisation du presse-papiers, logiciels malveillants et regards indiscrets restent des risques. Effacer retire les résultats de l’interface sans garantir leur effacement sécurisé en mémoire ni supprimer les copies externes.

Utiliser une clé générée en sécurité

Une chaîne aléatoire devient un identifiant API lorsque votre application l’enregistre et la vérifie. Configurez-y les droits minimaux, HTTPS, la révocation, l’expiration et la rotation. Ne placez pas les secrets serveur dans le code frontend ou un dépôt. Utilisez une gestion des secrets adaptée à la production. Pour les environnements sensibles, privilégiez une génération dans votre infrastructure de confiance. Les exemples Node.js, Python et OpenSSL créent de nouveaux secrets locaux sans reprendre ceux d’un site web. Aucun site ne garantit un navigateur ou un appareil non compromis.

Nos tests et leurs limites

Les tests de régression couvrent longueurs, vecteurs d’encodage connus, alphabets, échantillonnage par rejet, entropie, ajouts fixes, doublons, exports et sérialisation sûre des réglages. Les vérifications navigateur portent sur la génération, la copie, les exports, les mises en page traduites et la séparation des analyses. L’absence de doublons ou une répartition visuellement régulière ne prouve pas un aléa cryptographique. Cet outil n’est pas certifié indépendamment et nos tests ne constituent pas un audit de votre application entière.

Signaler un problème sans divulguer de secret

Indiquez le format, le mode de longueur, le nombre de bits ou caractères, la quantité, le navigateur et les étapes de reproduction. Fournissez un exemple inventé, jamais une clé active, un secret de webhook ou des données client. Notre politique de correction s’applique. Pour un défaut important confirmé, nous devons expliquer les fonctions concernées, ajouter un test de régression et préciser si les anciennes clés doivent être régénérées. Modifier cette page ne révoque pas les clés enregistrées ailleurs : remplacez-les ou révoquez-les dans ces systèmes.

Générer sur votre propre ordinateur

Les exemples créent un nouveau secret au format choisi, avec vos préfixe et suffixe. Ils n’intègrent jamais la clé affichée et ne créent ni compte, ni permission, ni règle d’expiration. Ils ne comprennent pas les identifiants publics ni les lots.

import { randomBytes } from 'node:crypto';
const key = randomBytes(32).toString('base64url');