Vercel KMS en beta: firma JWTs sin claves privadas

El problema clásico de firmar JWTs en serverless

Firmar un JSON Web Token (JWT) desde una función serverless suele ser un dolor de cabeza operativo: o guardas la clave privada en una variable de entorno (con el riesgo de fuga que eso implica), o montas un Vault externo, o recurres a un servicio de pagos para tokens de corta duración. Cualquiera de los tres caminos añade fricción cuando estás validando product-market fit o quieres escalar sin contratar a un equipo de seguridad.

Vercel acaba de mover ese problema a su propia infraestructura con Vercel KMS, un servicio en beta que firma JWTs y mensajes arbitrarios desde sus Vercel Functions sin que la clave privada viva en tu código, en tu .env ni en tu repositorio. Lo anunció el 18 de agosto de 2026 en su changelog oficial.

Qué hace exactamente Vercel KMS

Con Vercel KMS puedes crear y rotar emisores (issuers) y claves de firma en algoritmos RSA, ECDSA y EdDSA desde el dashboard o el CLI. El flujo es directo: tu función se autentica con su token de Vercel OIDC, y la operación de firma ocurre dentro del servicio de gestión de claves de Vercel, de modo que la clave privada nunca abandona esa frontera.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Según la documentación oficial de Vercel, los tokens OIDC de las funciones tienen un TTL de dos horas y Vercel los reusa durante un máximo de 90 minutos para evitar generar uno nuevo en cada invocación, cubriendo la duración máxima de ejecución de una función. Esa ventana es relevante: como KMS firma con ese mismo token OIDC, encaja bien con la lógica de credenciales de vida corta que ya promueve la plataforma.

Cada emisor publica dos endpoints públicos siguiendo el estándar OpenID Connect Discovery:

https://kms.vercel.com/<issuerId>/.well-known/openid-configuration
https://kms.vercel.com/<issuerId>/jwks.json

Eso significa que cualquier servicio externo puede verificar los tokens firmados con una librería JOSE estándar — jose, jsonwebtoken, PyJWT — sin acoplarse a SDKs propietarios de Vercel.

Funcionalidades clave que vienen incluidas

La release incluye un conjunto de capacidades pensadas para equipos que quieren control granular sin añadir complejidad:

Claims personalizados con TTL configurable al firmar JWTs, o firma de bytes crudos para casos no estándar.
Grants por entorno: producción, preview, development y entornos personalizados se gestionan por separado, de modo que una clave de preview no puede firmar tokens válidos en producción.
Restricción de claims por grant: puedes declarar un JSON Schema que limite qué claims puede pedir cada proyecto, y Vercel KMS valida la petición contra ese esquema antes de firmar.
Rotación y revocación aislada: como cada emisor es independiente, rotar o revocar la clave de un proyecto no afecta al resto.

El SDK para invocarlo es @vercel/kms, y el setup por CLI luce así:

vercel kms add my-issuer --algorithm ES256
vercel kms add-grant <issuerId> --project my-app --environment production

Necesitas Vercel CLI 59.1.0 o superior. El servicio está disponible en todos los planes durante la beta, aunque aplica el Beta Agreement y el comportamiento puede cambiar antes de la disponibilidad general.

Casos de uso reales para una startup

Lo que Vercel KMS resuelve de forma nativa es exactamente la clase de autenticación entre servicios que aparece tarde o temprano en cualquier producto SaaS en crecimiento. Tres ejemplos concretos:

Webhooks firmados hacia clientes: en lugar de inventar tu propio esquema de firma, tu función emite un JWT por evento y el cliente lo verifica contra el JWKS público de tu emisor. Si rotas la clave, el cambio se propaga sin tocar el lado del cliente.
Tokens de corta duración para integraciones B2B: cada vez que un partner llama a tu API, generas un JWT de 5 minutos con los scopes exactos que esa integración necesita. El claim se valida con el JSON Schema que declaraste.
Identidad entre microservicios: si tu backend es una mezcla de Vercel Functions y servicios en AWS, GCP o Azure, ya puedes delegar la firma a KMS y usar la Vercel OIDC Federation (que también soporta esos tres proveedores) para canjear el token por credenciales de corta duración en la nube. No hay claves de larga vida dando vueltas.

Qué significa esto para tu startup

Si hoy guardas una clave privada JWT en una variable de entorno, estás aceptando un riesgo que ya tiene solución de producto. Vercel KMS elimina el archivo private.pem que tarde o temprano termina en un log, en un backup o en el repositorio de un nuevo dev.

Dos acciones concretas que puedes implementar esta semana:

Audita dónde firmas JWTs a mano. Recorre tus funciones y detecta las que usan jsonwebtoken o jose con una clave en código o .env. Esos son los candidatos inmediatos a migrar a @vercel/kms. Empieza por el servicio que firma tokens para integraciones con clientes externos: es el más expuesto.
Mueve la verificación al estándar. Pide a tus partners que verifiquen tus tokens contra el endpoint jwks.json del emisor, en lugar de hardcodear la clave pública. Cuando rotes, no tendrás que coordinar un rollout manual: la firma anterior deja de ser válida automáticamente.

La mejor práctica que recomienda la propia documentación es crear un emisor separado por proyecto y por entorno, para que cada token tenga una audiencia distinta y una rotación o revocación no afecte al resto. Es una disciplina barata de aplicar desde el día uno, y te evita el clásico incidente de "rotamos la clave de producción y se cayeron los previews".

El contexto más amplio importa: Vercel ya soporta OIDC Federation hacia AWS, GCP y Azure, y su feature Passport (Enterprise) añade protección de despliegues con proveedores como Okta y Microsoft Entra ID. KMS es el siguiente ladrillo de una estrategia de seguridad por defecto que la plataforma está construyendo para que equipos pequeños operen como empresas grandes sin contratar a un CISO.

Conclusión

Vercel KMS no es una feature revolucionaria en el sentido conceptual — la firma gestionada de JWTs ya existía en AWS KMS, Google Cloud KMS o HashiCorp Vault. Lo que cambia es el punto de integración: ahora vive al lado de tus funciones, se configura con un comando del CLI y cuesta cero adoptarlo si ya despliegas en Vercel. Para founders hispanohablantes que iteran rápido sobre Next.js o microservicios en la plataforma, eso convierte la gestión de claves en algo que resuelves en 15 minutos, en lugar de en una épica de seguridad de varias semanas.