0 bits d'entropie
Longueur de clé
Encodage
Des clés API aléatoires en caractères sûrs pour les URL et le shell, générées dans votre navigateur. Aucun réseau, aucun journal, aucun envoi.
Appuyez sur Espace pour regénérer, C pour copier. Généré par crypto.getRandomValues sur votre appareil ; la page ne charge aucune ressource externe.
Une clé API n'est pas une clé cryptographique au sens où les autres générateurs de ce site en produisent : rien ne signe ni ne déchiffre avec elle. C'est une longue chaîne aléatoire que votre serveur reconnaît, si bien que la seule propriété qui compte est que personne ne puisse la deviner ni en fabriquer une autre que votre serveur accepterait. 128 bits d'aléa la placent déjà hors d'atteinte ; 256 est ce sur quoi la plupart des services s'arrêtent.
Les octets proviennent de crypto.getRandomValues, le générateur de nombres aléatoires cryptographiquement sûr du navigateur, puis sont écrits en Base64URL ou en hexadécimal. Les deux alphabets traversent une URL, un en-tête HTTP, une variable d'environnement et une commande shell sans échappement — d'où l'absence ici du Base64 ordinaire, avec ses caractères +, / et =. Ni horodatage, ni compteur, ni Math.random sur ce chemin.
Tout se passe sur votre appareil. La page n'émet aucune requête réseau une fois chargée : cette clé n'a donc jamais existé ailleurs et ne circule nulle part. Rechargez et elle disparaît, ce qui veut aussi dire qu'il faut la coller dans votre coffre à clés avant de fermer l'onglet.
128 bits d'aléa — soit 22 caractères en Base64URL — sont déjà hors de portée de la force brute, et personne ne trouvera une telle clé en devinant à travers votre limiteur de débit. 256 bits est la valeur par défaut courante, surtout parce qu'elle ne coûte rien et évite que la question ressurgisse en revue. Au-delà, la longueur n'apporte aucune sécurité supplémentaire : elle rend seulement la clé plus pénible à coller et plus exposée à la troncature par une ligne de journal ou une colonne de base de données en chemin.
C'est possible, mais moins solide qu'il n'y paraît. Un UUIDv4 aléatoire porte 122 bits et non 128, six d'entre eux étant des marqueurs fixes de version et de variante — cela reste suffisant, mais uniquement si un CSPRNG se trouve derrière, et bien des implémentations se rabattent discrètement sur le générateur aléatoire ordinaire. UUIDv1 et v7 embarquent un horodatage et sont partiellement prévisibles par conception. Un UUID s'annonce en outre comme un identifiant, ce qui incite tout ce qui suit à le traiter comme tel et à le journaliser.
Oui, si vous émettez des clés plutôt que d'en consommer. Un sk_live_ ou un myapp_ rend une clé fuitée identifiable d'un coup d'œil et, plus utile encore, donne aux analyseurs de secrets de GitHub et GitLab un motif à reconnaître : une clé publiée par mégarde est signalée au lieu de rester là. Il permet aussi de router ou de rejeter sur le préfixe avant de toucher la base. Ajoutez-le devant la valeur de cette page : un préfixe n'est pas secret et n'apporte aucune entropie, il ne remplace donc aucune partie de l'aléa.
Hachée, exactement comme un mot de passe : une clé lisible dans votre base est une fuite qui n'attend que d'être exportée. À la différence d'un mot de passe, un simple SHA-256 suffit ici et un hachage lent comme bcrypt est inutile : la clé est déjà 128 bits d'aléa uniforme, il n'y a aucun dictionnaire à lui opposer ni raison de payer ce coût à chaque requête. Conservez en clair un préfixe ou les quatre derniers caractères pour pouvoir l'identifier dans une liste, et n'affichez la valeur complète qu'une seule fois, à la création.
Une clé API est opaque : elle ne signifie rien en dehors du système qui l'a émise, lequel doit la rechercher pour la vérifier. Un JWT est l'inverse — il porte ses assertions et son expiration en lui-même, signées, si bien qu'un service peut le vérifier sans aucune recherche. Les jetons au sens d'OAuth se rapprochent du JWT : courte durée de vie, portée limitée, émis après une autre authentification. Prenez une clé quand une machine a besoin d'un accès durable qu'elle peut garder dans un fichier de configuration, et un jeton quand l'accès doit expirer de lui-même.
Les mêmes octets dans les deux cas ; ce qui change, c'est la longueur et les endroits où la chaîne survit sans échappement. Base64URL est plus court — 256 bits font 43 caractères contre 64 en hexadécimal — et son alphabet se limite à A-Z, a-z, 0-9, au tiret et au tiret bas, qui passent tous intacts dans les URL, les en-têtes et les shells. L'hexadécimal est plus long mais plus facile à lire à voix haute, à dicter et à comparer à l'œil, et il ne bute jamais sur ce qui gère mal la casse. Celui qu'il faut éviter, c'est le Base64 ordinaire : + et / demandent un échappement dans une URL, et le remplissage = se fait régulièrement retirer en route.
Évitez. Les chaînes de requête sont inscrites dans les journaux d'accès du serveur, ceux des mandataires et l'historique du navigateur, et elles fuient par l'en-tête Referer vers ce que la page pointe ensuite — rien de tout cela n'est sous votre contrôle une fois la requête partie. Envoyez plutôt la clé dans un en-tête Authorization, sous la forme Authorization: Bearer suivi de la clé, qu'aucun journal ordinaire n'enregistre par défaut. L'alphabet compatible URL utilisé ici sert au segment de chemin occasionnel ou au rappel d'un webhook, pas à faire de la chaîne de requête un bon endroit pour un secret.
Avec bien moins de cérémonie qu'une clé cryptographique : changer une clé API ne rechiffre rien, tout le coût tient dans la coordination des clients. Laissez chaque compte détenir deux clés actives en même temps et la rotation se réduit à créer, déployer, révoquer, sans fenêtre pendant laquelle l'intégration tombe. Sur calendrier, une à deux fois par an suffit à la plupart des systèmes. Ce qui compte bien davantage, c'est que la révocation soit immédiate et en libre-service, car la rotation qui compte vraiment est celle qu'on n'avait pas prévue.
Uniquement si la page ne peut pas la transmettre, et cela se vérifie au lieu de se supposer. Ouvrez les outils de développement, restez sur l'onglet Réseau et générez autant de clés que vous voulez : rien n'est demandé après le chargement. Aucun serveur derrière pour recevoir quoi que ce soit, aucune mesure d'audience ni script tiers pour la laisser fuir. La clé ne vit que dans la mémoire d'un onglet jusqu'à ce que vous la colliez quelque part, et disparaît au rechargement.