Vercel fija plazos para los proveedores: las claves estáticas desaparecerán en 2027

Vercel quiere hacer con las claves de API lo que Google y Let's Encrypt hicieron con el cifrado del tráfico. La compañía encuestó a más de 1000 proveedores SaaS y concluyó que solo el 8,4% admite autenticación segura entre servicios. El resto sigue entregando contraseñas de bases de datos y claves de API sin fecha de caducidad. Para mover el mercado, Vercel impone plazos estrictos a los socios de su Marketplace: desde el 30 de noviembre de 2026, los proveedores que no admitan la autenticación OIDC de Vercel y se apoyen en secretos de larga duración llevarán la etiqueta «Not secure» en su ficha. Desde enero de 2027, esos proveedores serán eliminados del catálogo.

Por qué la clave estática se ha convertido en un problema ahora

Un secreto estático de larga duración es una clave de API o una contraseña que la aplicación usa una y otra vez, a menudo sin fecha de caducidad. Una clave así puede filtrarse a un repositorio o a un chat, y también puede robarse a través de una dependencia comprometida. Ahora se suma otra vía: la prompt injection, que obliga al agente a revelar sus propias credenciales. Además, los agentes reciben acceso a sistemas y datos mediante claves cuyos permisos suelen ser más amplios de lo que exige la tarea concreta.

Cifrar los secretos en disco no resuelve el problema: el código malicioso en producción lee las variables de entorno igual que la propia aplicación. Mientras la clave no haya caducado ni haya sido revocada, cualquiera puede usarla. Y rotarlas sale caro. Según Vercel, su equipo ya ha realizado varias rotaciones dolorosas por precaución y ha invertido en ellas miles de horas de ingeniería. La compañía no quiere repetirlo.

Qué propone Vercel en lugar de las claves

La alternativa se conoce desde hace tiempo: OIDC. Un emisor de confianza genera un token firmado y de corta duración que identifica a la aplicación; el servicio receptor lo verifica y decide qué acceso concede. Un token robado deja de funcionar cuando expira. La aplicación obtiene los tokens nuevos de forma programática, así que no hace falta distribuir ni cambiar a mano una clave permanente.

La federación OIDC en Vercel está disponible desde 2024: las aplicaciones intercambian los tokens de la plataforma por credenciales temporales de AWS, Google Cloud y Azure, según las políticas de confianza configuradas para el proyecto y el entorno. Ahora la compañía extiende este enfoque a sus propios servicios Blob, AI Gateway y Sandbox, así como a la API y la CLI de Vercel, con el fin de eliminar los tokens de larga duración de los procesos de despliegue.

Las nuevas herramientas son estas:

• OIDC UI: un registro de componentes de shadcn/ui con un configurador de trust-policy y un verificador de tokens en el servidor. Incluye formularios listos para Vercel, GitHub, GitLab, Google, Bitbucket, AWS, Azure y emisores OIDC arbitrarios.
• Vercel Connect: las aplicaciones y los agentes solicitan tokens de proveedores en tiempo de ejecución a partir de la identidad del despliegue. En el código basta una llamada a getToken que indique el usuario y los scopes, por ejemplo para acceder a Linear.
• Custom audience: el token queda vinculado a un único servicio receptor.
• Ejemplo con Azure: ClientAssertionCredential intercambia el token de Vercel por acceso a Cosmos DB sin necesidad de la clave de la base de datos.

Latencia e incentivos

Vercel reconoce que la clave estática tiene una ventaja: ya está en una variable de entorno y no requiere ninguna petición de red. Obtener e intercambiar tokens añade latencia. Por eso las funciones de Vercel reciben el token de la plataforma en una cabecera de la petición, y el SDK lo lee sin hacer una llamada adicional. La plataforma reutiliza los tokens que no han expirado, y Vercel Connect almacena en caché los tokens de los proveedores dentro del proceso y los renueva cerca del final de su vigencia. Las llamadas de red solo quedan para la custom audience y para el intercambio por tokens de proveedores.

Además de la comodidad y la velocidad, Vercel señala un tercer obstáculo: los proveedores tienen pocos incentivos para ocuparse de esto. Aquí entra el ejemplo de Chrome, que primero marcó HTTP como «Not secure» y después fijó plazos. Vercel se propone seguir el mismo camino y promete aplicar los mismos requisitos a su propia API y a sus integraciones nativas. Además, la compañía quiere que las integraciones del Marketplace configuren la autenticación segura de forma automática al conectar el servicio, sin un paso aparte.

Qué deben hacer desarrolladores y proveedores

Si construyes un producto para clientes de Vercel, antes del 30 de noviembre tendrás que decidir si aceptas los tokens OIDC directamente o si los intercambias por credenciales temporales. Los componentes de OIDC UI permiten no escribir desde cero ni el formulario de configuración de confianza ni la verificación de tokens. Si simplemente usas servicios a través del Marketplace, conviene revisar con antelación con qué proveedores conectados guardas claves permanentes en variables de entorno y preparar un plan para sustituirlas.

Para las aplicaciones con agentes, el punto de partida lógico es Vercel Connect: un token para un usuario concreto y unos scopes concretos limita el daño en caso de prompt injection. Tras la migración, conviene revocar las claves antiguas en lugar de limitarse a dejar de usarlas.