|

Vercel y las credenciales estáticas: la contradicción

En pocas palabras: Sí, hay doble estándar: Vercel le exige a vendors del Marketplace migrar a OIDC antes de enero de 2027, pero su propio flujo de GitHub Actions todavía depende del VERCEL_TOKEN, una credencial estática de larga duración que la empresa busca eliminar del resto del ecosistema.

Vercel anunció, en un comunicado del jueves, que va a eliminar las API keys estáticas de su ecosistema, con un plazo hasta enero de 2027 para que los vendors del Marketplace migren a OIDC. El problema: su propio flujo de GitHub Actions todavía pide un token fijo, el VERCEL_TOKEN, para desplegar.

Las credenciales estáticas son claves de acceso que no caducan y quedan guardadas en variables de entorno o secretos de CI/CD. OIDC (OpenID Connect) es el protocolo que Vercel impulsa como reemplazo: en vez de guardar una clave fija, cada despliegue recibe un token firmado que vence en minutos u horas. La diferencia central es el tiempo de vida de la credencial, no el método de login.

Resumen

  • Vercel encuestó a más de 1.000 vendors SaaS y solo el 8.4% usaba autenticación que la empresa considera segura, según el anuncio del CTO Malte Ubl.
  • El plazo para que el Marketplace adopte OIDC o tokens de corta duración vence en enero de 2027.
  • Desde el 30 de noviembre de 2026, los listados que no cumplan van a mostrar una advertencia “Not secure”.
  • La guía oficial de GitHub Actions de Vercel todavía exige un VERCEL_TOKEN estático para desplegar.
  • Vercel Connect permite credenciales de corta duración en runtime, pero su documentación admite que proveedores sin OAuth sigan usando claves fijas.

¿Qué anunció Vercel sobre las credenciales estáticas?

Vercel confirmó que va a sacar del Marketplace a los vendors que sigan dependiendo de API keys de validez indefinida. El CTO Malte Ubl explicó en el anuncio del jueves que la empresa relevó a más de 1.000 proveedores SaaS y encontró que solo el 8.4% usaba lo que Vercel clasifica como autenticación segura.

Ese número es el que justifica todo el movimiento. Si menos de uno de cada diez vendors cumple el estándar, el riesgo no es hipotético: es la norma del ecosistema. Guillermo Rauch, CEO de Vercel, amplificó el mensaje en X diciendo que “es hora de matar las credenciales estáticas” y que los tokens robados deberían comportarse como “self-destructing keys” (claves autodestructivas) que caducan antes de que un atacante pueda explotarlas.

El contexto no es casualidad. La industria viene de una ola de ataques a la cadena de suministro, incluido un worm en npm que scrapeaba tokens directamente de pipelines de CI. Ponele que un paquete comprometido entra a tu build, encuentra una API key guardada en una variable de entorno y la manda a un servidor externo: con una credencial estática, esa clave sigue funcionando días o meses después. Con OIDC, el token ya venció antes de que el atacante termine de armar el exploit. En si desplegás un proyecto React Vite en Vercel profundizamos sobre esto.

¿Qué es OIDC y por qué Vercel lo propone como alternativa a las API keys?

credenciales estáticas vercel diagrama explicativo

OIDC (OpenID Connect) es un protocolo que emite tokens de corta duración firmados por un proveedor de identidad, en reemplazo de claves fijas que quedan guardadas sin vencimiento. Según la documentación oficial de Vercel, estos tokens son firmados por el Identity Provider (IdP) propio de la plataforma y proveedores como AWS, Google Cloud y Microsoft Azure pueden confiar en ellos para emitir credenciales de corta duración a cambio.

La feature está disponible en todos los planes de Vercel. Tiene tres beneficios concretos según la propia documentación:

  • Sin credenciales persistidas: no hace falta copiar y pegar access tokens del cloud provider en las variables de entorno de Vercel.
  • Control de acceso granular: podés separar permisos por proyecto o por entorno (desarrollo, preview, producción) y que cada token OIDC solo acceda a lo que corresponde.
  • Acceso en desarrollo local: se puede configurar el cloud provider para confiar en entornos locales sin guardar credenciales fijas en la máquina del desarrollador.

En la práctica, los builds de Vercel generan automáticamente un token y lo asignan a la variable VERCEL_OIDC_TOKEN. En las Functions, ese mismo token viaja en el header x-vercel-oidc-token. Vercel no genera un token nuevo en cada ejecución: lo reutiliza hasta 90 minutos, con un TTL total de dos horas. Esa feature pasó por beta en julio de 2024 según el changelog original.

¿Por qué el propio flujo de GitHub Actions de Vercel sigue dependiendo de un token estático?

Porque la guía oficial de despliegue de GitHub Actions todavía instruye a los desarrolladores a usar un secreto VERCEL_TOKEN para autenticar los deploys, el mismo tipo de credencial persistente que la empresa le pide al resto del ecosistema que abandone. Es la contradicción que disparó la discusión pública.

Yordis Prieto, ingeniero senior de software en Fanatics, lo marcó directo en su respuesta al anuncio: escribió que Vercel “inventó” OIDC federation y sin embargo él todavía depende de “un token de acceso de larga duración” en su pipeline de CI. Pidió que la empresa saque ese requisito de GitHub Actions y criticó que exista una opción de token sin expiración.

¿Vercel respondió con una fecha concreta? No. Ubl dijo en el anuncio que la compañía está extendiendo soporte OIDC a su API y su CLI para retirar los tokens de larga duración de los flujos de despliegue, pero sin cronograma publicado para GitHub Actions específicamente. Mientras tanto, cualquier equipo que despliegue con ese flujo sigue guardando el mismo tipo de secreto que Vercel le pide a sus vendors que eliminen antes de 2027. Relacionado: nuestra guía para desplegar tu web gratis.

¿Vercel Connect eliminó las claves estáticas o todavía las permite?

Vercel Connect todavía permite claves estáticas para proveedores que no tienen OAuth u otra opción basada en identidad. El servicio resuelve parte del problema dejando que aplicaciones y agentes pidan credenciales con alcance limitado en tiempo de ejecución, usando la identidad del despliegue en lugar de guardar secretos en el entorno de la aplicación, pero no cerró la puerta a las claves fijas.

El 15 de octubre de 2026, Vercel sumó autorización gestionada a nivel empresarial en beta pública, lo que permite que administradores controlen el acceso a servicios soportados a través de proveedores de identidad como Okta. Eso suma una capa de control. Ahora bien, la documentación de Connect sigue describiendo el almacenamiento centralizado de API keys estáticas, con la clave subyacente viviendo de forma indefinida en el sistema.

A fines de septiembre, Vercel también metió autenticación GitHub OIDC para su Container Registry. Esa movida mejora un flujo puntual, pero no toca el requisito de VERCEL_TOKEN en el deploy documentado de GitHub Actions. Son piezas separadas del mismo rompecabezas, y todavía no encajan del todo.

¿Qué plazos y sanciones enfrentan los vendors del Marketplace que no cumplan?

Desde el 30 de noviembre de 2026, las integraciones del Marketplace que no cumplan los requisitos de autenticación de Vercel van a mostrar una advertencia “Not secure” en su listado. El plazo final para migrar o quedar fuera del Marketplace es enero de 2027. Sobre eso hablamos en la comparativa entre Vercel y AWS Amplify.

Lo que no está claro: Vercel no publicó la metodología de su encuesta a los más de 1.000 vendors, no nombró a las empresas relevadas y no dijo cuántos partners actuales del Marketplace van a tener que cambiar su sistema de autenticación para seguir listados. Esos tres datos son los que faltan para evaluar si el 8.4% es representativo de todo el ecosistema o de una muestra particular.

¿Qué implica esto en la práctica para equipos que despliegan con Vercel?

Implica revisar dos cosas por separado: cómo autenticás tus propios pipelines de CI contra Vercel, y cómo autenticás las integraciones de terceros que usás desde el Marketplace. Son problemas distintos con plazos distintos.

Si usás GitHub Actions para desplegar, hoy seguís necesitando el VERCEL_TOKEN que la guía oficial pide. No hay alternativa documentada todavía para ese flujo puntual. Si en cambio conectás servicios externos vía Vercel Connect, ya podés aprovechar OIDC para AWS, GCP o Azure, y sumarle autorización por identidad con Okta si tu organización la usa. El criterio práctico más simple: contá cuántos secretos estáticos tenés guardados hoy en variables de entorno de Vercel que podrían caducar con OIDC, y empezá por los que tocan producción.

Qué está confirmado y qué no

Confirmado: la encuesta a más de 1.000 vendors con 8.4% de cumplimiento, el plazo de enero de 2027, la advertencia “Not secure” desde el 30 de noviembre de 2026, el soporte OIDC disponible en todos los planes de Vercel y la persistencia del VERCEL_TOKEN en la guía oficial de GitHub Actions.

No confirmado: la metodología de la encuesta, los nombres de las empresas relevadas, una fecha concreta para sacar el requisito de token estático de GitHub Actions, y cuántos partners actuales del Marketplace quedarían afectados por el cambio.

Errores comunes al migrar de API keys estáticas a OIDC

  • Asumir que activar OIDC borra las claves viejas: no es así. Si no revocás manualmente las API keys estáticas existentes en tu cloud provider, siguen activas en paralelo aunque ya tengas OIDC configurado.
  • Olvidar el modo de issuer: Vercel ofrece issuer “Team” (recomendado, con URL propia por equipo) o “Global” (URL genérica). Elegir mal complica la configuración de confianza del lado de AWS, GCP o Azure.
  • No cachear mal el token en Functions: la documentación advierte que Vercel reutiliza el token OIDC hasta 90 minutos con un TTL de dos horas. Si tu código cachea el token por más tiempo, podés terminar usando un token vencido.
  • Confundir Connect con una solución total: Connect reduce la exposición en runtime, pero su propia documentación admite que sigue permitiendo claves estáticas para proveedores sin OAuth. No resuelve el problema para todos los casos.

Preguntas Frecuentes

¿Qué anunció Vercel sobre las credenciales estáticas?

Vercel anunció que va a exigirle al Marketplace abandonar las API keys de larga duración, dándole a los vendors hasta enero de 2027 para migrar a OIDC o tokens de corta duración. El CTO Malte Ubl basó la medida en una encuesta propia a más de 1.000 vendors SaaS, de los cuales solo el 8.4% cumplía el estándar de autenticación que Vercel considera seguro.

¿Qué es OIDC y en qué se diferencia de una API key estática?

OIDC es un protocolo que emite tokens firmados con vencimiento corto, en lugar de una clave fija que queda válida de forma indefinida. La diferencia clave es el tiempo de vida: una API key estática sigue funcionando hasta que alguien la revoca manualmente, mientras que un token OIDC caduca solo, en el caso de Vercel hasta en dos horas para las Functions.

¿Por qué el GitHub Actions de Vercel todavía usa un token estático?

Porque la guía oficial de despliegue de Vercel para GitHub Actions sigue pidiendo un secreto VERCEL_TOKEN sin fecha de vencimiento. Vercel dijo que está extendiendo OIDC a su API y CLI, pero no publicó un cronograma específico para eliminar ese requisito del flujo de GitHub Actions.

¿Qué pasa si un vendor del Marketplace no migra a OIDC antes de 2027?

Desde el 30 de noviembre de 2026, su listado va a mostrar una advertencia “Not secure” visible para quien lo busque en el Marketplace. Si para enero de 2027 sigue sin cumplir los requisitos de autenticación de Vercel, corre riesgo de ser retirado del Marketplace.

¿Vercel Connect eliminó las claves de API estáticas?

No, todavía no. Vercel Connect permite credenciales con alcance limitado en runtime y maneja la renovación de tokens, pero su propia documentación admite que los proveedores sin OAuth siguen pudiendo usar API keys estáticas, con la clave subyacente viviendo de forma indefinida en el sistema.

Conclusión

Vercel tiene razón en el diagnóstico: con solo 8.4% de más de 1.000 vendors usando autenticación segura, las credenciales estáticas son un problema real del ecosistema, no una excusa teórica. El tema es que exigirle al resto algo que tu propia infraestructura todavía no cumple del todo le resta fuerza al mensaje. Mientras el VERCEL_TOKEN siga en la guía oficial de GitHub Actions, cualquier equipo que despliegue así va a seguir guardando el mismo tipo de secreto que la empresa quiere erradicar en todos los demás.

Si gestionás infraestructura en Vercel, el paso concreto es auditar hoy qué credenciales estáticas tenés activas (tanto en tus propios pipelines como en las integraciones del Marketplace que usás) y priorizar la migración a OIDC donde ya está disponible, que es prácticamente todo salvo GitHub Actions. Para hosting y dominios en Argentina, donweb.com es una alternativa a evaluar si además necesitás infraestructura local con soporte en español.

Fuentes

Te puede interesar...