Generador de API key

Qué es una API key y cuándo usarla

Una API key es una cadena secreta que un cliente envía en cada pedido HTTP para autenticarse. A diferencia de un usuario y contraseña, está pensada para autenticar servicios, no personas. Aparece en cabeceras como Authorization: Bearer ... o en parámetros tipo ?api_key=....

Las API keys son ideales para integraciones servidor-a-servidor (un script que llama a Stripe, un cron que sube archivos a S3) y para herramientas de testing. No son la mejor opción para clientes finales: ahí conviene OAuth o JWT firmados.

Cómo generamos la clave

Cada caracter sale de crypto.getRandomValues, la API criptográfica del navegador, mapeado al alfabeto que elijas:

• Hexadecimal: 16 caracteres posibles (0-9, a-f). 4 bits por caracter.
• Base62: 62 caracteres (A-Z, a-z, 0-9). Aproximadamente 5,95 bits por caracter.
• Base64 URL-safe: 64 caracteres (incluye - y _). 6 bits por caracter, ideal para tokens en URLs sin escapado.

Recomendaciones de longitud y entropía

Una API key debería tener al menos 128 bits de entropía. Eso se traduce en:

1. 32 caracteres en hex.
2. 22 caracteres en base62.
3. 22 caracteres en base64url.

Para tokens críticos (claves maestras, claves de webhook con privilegios amplios) llevá la entropía a 256 bits: 64 hex, 43 base62 o 43 base64url. Stripe usa 32+ caracteres random tras el prefijo. GitHub usa 40 caracteres hexadecimales en sus PATs.

Buenas prácticas con prefijos

Un prefijo legible facilita la operación día a día. Convenciones que funcionan:

• sk_ para "secret key" (uso solo desde servidor).
• pk_ para "publishable key" (puede aparecer en frontend).
• _live_ y _test_ para distinguir producción de sandbox.
• Prefijo de producto: ghp_ (GitHub PAT), xoxb- (Slack bot).

El prefijo también permite que herramientas como GitGuardian o TruffleHog detecten claves filtradas en repositorios públicos. Si tu prefijo es genérico, esos escáneres no lo van a encontrar.

Almacenamiento y rotación

Generar la clave es solo el principio. Para que sea segura en serio:

• Nunca la commitees al repositorio. Usá variables de entorno o un secret manager (AWS Secrets Manager, Vault, Doppler, 1Password CLI).
• Almacená un hash, no el texto plano. Si tu base de datos se filtra, las claves siguen siendo inservibles. Mostrá la clave una sola vez, cuando se crea.
• Rotá periódicamente. Cada 90 días para producción, inmediato si sospechás filtración.
• Limitá scopes. Una clave con permisos mínimos limita el daño si se filtra.
• Logueá uso. IP, user agent y endpoint te permiten detectar abuso temprano.

Errores frecuentes

Vemos los mismos problemas una y otra vez en proyectos reales:

• API keys en el bundle de JavaScript del frontend.
• Claves "temporales" en Slack que nunca se rotan.
• Una sola clave compartida por todo el equipo.
• Sin expiración, sin último uso registrado, sin forma de saber si está activa.
• Reutilización entre entornos (la clave de test funciona en producción).