Gerador de Token / Chave de API

Quando usar cada formato?

• • Hexadecimal: chaves de API, tokens de sessão, segredos de webhook
• • Alfanumérico: códigos de verificação, tokens legíveis
• • Base58: URLs curtas, tokens sem caracteres ambíguos (sem 0, O, I, l)
• • UUID v4: identificadores únicos de recursos, IDs de banco de dados

Tokens de autenticação sem mistério

Um token é uma string opaca que um cliente autenticado envia ao servidor no lugar de usuário e senha. Sistemas diferentes usam formatos diferentes de token, dependendo do tempo de vida, de quem emite e do que ele protege:

• API keys — credenciais de longa duração emitidas para um projeto ou máquina; geralmente rotacionadas manualmente.
• Bearer tokens (RFC 6750) — qualquer coisa em Authorization: Bearer …; quem possui está autorizado.
• Session tokens — IDs armazenados no servidor e gravados em cookie; revogados no logout.
• Access tokens OAuth — curta duração (~1h), atrelados a um escopo e usuário específicos.
• Refresh tokens — longa duração (30+ dias), usados só para obter novos access tokens.
• CSRF tokens — ligados à sessão e/ou requisição, rotacionados em cada formulário.
• Magic links — tokens de uso único enviados por e-mail ou SMS para login sem senha.

Quanta entropia é suficiente

A OWASP recomenda no mínimo 128 bits (16 bytes) de entropia para tokens de sessão — isso dá ao atacante um espaço de busca de 2¹²⁸. Chaves criptográficas (de assinatura, de cifra simétrica) devem mirar em 256 bits (32 bytes). A codificação não muda a entropia, só o tamanho do texto: hex usa 2 chars por byte, base64 usa 4 chars a cada 3 bytes, base64url é URL-safe (sem +, /, =) e base32 (variante Crockford) evita caracteres ambíguos.

Formatos comuns

UUIDv4 empacota 122 bits aleatórios efetivos em um layout fixo de 36 caracteres. nanoid usa por padrão 21 caracteres URL-safe (~149 bits). ULID usa 26 caracteres e é ordenável no tempo, útil como chave primária. Para a maioria dos tokens de sessão/API, uma string base64url de 32 caracteres (192 bits) é o ponto ótimo entre tamanho e segurança.

CSPRNG vs Math.random

Nunca gere tokens de produção com Math.random() — é um PRNG rápido com seed previsível, não criptograficamente seguro. Use o CSPRNG da plataforma:

// Browser
const buf = new Uint8Array(32)
crypto.getRandomValues(buf)

// Node.js
require('crypto').randomBytes(32).toString('base64url')

// Python
import secrets; secrets.token_urlsafe(32)

// Java
new java.security.SecureRandom().nextBytes(buf)

Armazenamento e rotação

Nunca logue tokens em texto puro, nunca comite no git e nunca os exponha em URLs salvo se forem de uso único. Mantenha em variáveis de ambiente ou em um secrets manager (Vault, AWS Secrets Manager, Doppler), rotacione periodicamente e revogue os comprometidos via deny-list ou TTL curto. JWT é self-contained (claims assinadas pelo servidor, validadas sem estado) enquanto um token opaco é apenas uma string aleatória que requer lookup a cada requisição — o opaco é mais fácil de revogar; o JWT escala melhor, mas a revogação é mais complexa.

Perguntas frequentes

Este gerador usa CSPRNG? Sim. Ele chama crypto.getRandomValues() no seu navegador, que é o RNG criptograficamente seguro da Web Crypto API.

É seguro usar esses tokens em produção? Tecnicamente sim — os bytes são criptograficamente fortes — mas a boa prática é gerar tokens no backend para que nunca trafeguem pelo front-end nem fiquem no histórico do navegador.

Qual comprimento devo escolher? 32+ caracteres URL-safe atende a maior parte dos casos. Vá para mais (48–64) em refresh tokens e chaves de assinatura; UUIDv4 (122 bits) é aceitável para identificadores não-secretos.