Générateur de clés API

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.

Supposons que votre application accepte 48 caractères au maximum, préfixe dev_ compris. Avec 256 bits, Base64URL apporte 43 caractères aléatoires ; le préfixe de quatre caractères porte donc le total à 47. Hex apporte 64 caractères aléatoires et donnerait 68 au total, ce qui ne tient pas. Un suffixe consomme la même limite. La longueur aléatoire et la longueur totale affichées par l’outil répondent à deux questions différentes : la première décrit la partie aléatoire du secret, la seconde indique ce que le champ destinataire doit accepter. La RFC 4648 explique pourquoi des représentations des mêmes octets ont des longueurs différentes. Vérifiez aussi l’alphabet accepté par le destinataire, pas seulement sa limite, avant de choisir le format le plus court.

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.

Pour un alphabet personnalisé, imprimable signifie ici ASCII sans espace : les lettres accentuées, emoji, tabulations et espaces sont refusés. Après déduplication et éventuelle exclusion des caractères similaires, il doit rester au moins deux choix distincts. Si l’alphabet devient invalide, modifiez-le explicitement au lieu d’attendre de l’outil qu’il en substitue un autre. Les préfixes et suffixes suivent une autre règle : chacun peut contenir jusqu’à 32 lettres ASCII, chiffres ou symboles _ . : -. Une chaîne acceptée comme alphabet ne l’est pas forcément comme libellé.

Le nombre exact de caractères s’applique aux alphabets de caractères, pas aux encodages d’octets. Une limite de champ fixe ne garantit pas une quantité fixe d’aléa. Par exemple, 32 caractères hexadécimaux choisis uniformément offrent 128 bits théoriques, tandis que 32 choix dans un alphabet de 64 caractères distincts en offrent 192. Si le champ est trop court pour la taille requise par l’application, ne tronquez pas une valeur déjà générée et ne comptez pas son libellé comme des caractères aléatoires. Choisissez une représentation compatible et vérifiez le calcul obtenu avant de générer ; si aucune combinaison autorisée ne tient, l’exigence de l’application doit être clarifiée.

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.

Masquer les résultats est utile quand l’écran est visible par d’autres personnes, mais les 24 points de masquage sont une convention d’affichage, pas la longueur du secret. La copie et l’export contiennent toujours les vraies valeurs. Modifier les réglages de génération efface le lot affiché, y compris lors d’un changement de format : cela prépare une nouvelle génération au lieu de convertir l’ancien secret dans un autre encodage. Transférez en sécurité le lot dont vous avez besoin avant de changer ces réglages. Dans la fenêtre d’export, le format de fichier ou le séparateur TXT ne fait que reformater ce même lot.

Seuls 20 résultats sont affichés par page, mais Tout copier et l’export utilisent tout le lot. Avec les paires d’identifiants activées, un bouton Copier individuel copie uniquement le secret. Sans paires, JSON est un tableau de chaînes ; avec paires, c’est un tableau d’objets dotés des champs key_id et api_key. Vérifiez que votre code d’import attend cette structure au lieu de traiter l’identifiant public comme un second secret ou de supposer que la première page visible est tout le téléchargement. Gardez l’identifiant choisi associé au secret lorsque vous enregistrez les informations d’identification.

Choisissez JSON lorsqu’une machine doit recevoir exactement les caractères du secret. CSV est préparé pour l’affichage dans un tableur : une valeur commençant comme une formule, par exemple -example, peut recevoir une apostrophe initiale, si bien qu’un parseur CSV générique peut lire une valeur littérale différente. L’exemple est inventé, pas une clé utilisable. Ne retirez pas systématiquement les apostrophes de toutes les clés importées ; une apostrophe peut aussi provenir réellement de l’alphabet. Les recommandations de l’OWASP sur l’injection CSV expliquent l’interprétation des formules et les limites de l’échappement pour tableur. Réenregistrer un CSV dans un tableur n’est pas une garantie universelle de sécurité et ajoute une manipulation inutile pour un secret de production.

Pour .env, un nom comme APP_TOKEN est valide ; 1TOKEN ou APP-TOKEN ne l’est pas. L’outil limite le nom à 64 caractères et refuse les valeurs contenant un guillemet double ou une barre oblique inverse, au lieu de deviner comment un autre chargeur les interprétera. Node.js documente sa propre syntaxe dotenv ; vérifiez séparément la compatibilité avec les autres logiciels qui liront le fichier. Si l’export refuse une valeur issue d’un alphabet personnalisé, utilisez JSON ou un transfert contrôlé adapté à cette application. Renommer un fichier téléchargé ne retire pas les caractères incompatibles, et un fichier .env contenant des secrets doit toujours être stocké de manière protégée.

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.

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. Ces tests automatisés ne démontrent pas la fiabilité dans tous les navigateurs et sur tous les appareils, ni le fonctionnement du presse-papiers du système, de l’enregistrement des fichiers ou des outils d’analyse sur le site publié.

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') + "";

Questions fréquentes

Sources et outils associés

Méthodologie et limites: Web Crypto · RFC 4648

Générateur de GUID · Méthodologie et limites · Politique de correction