Vercel fixe des échéances aux éditeurs : les clés statiques disparaîtront d'ici 2027

Vercel veut faire pour les clés d'API ce que Google et Let's Encrypt ont fait pour le chiffrement du trafic. L'entreprise a interrogé plus de 1000 éditeurs SaaS et constate que seuls 8,4% prennent en charge une authentification sécurisée entre services. Les autres continuent de distribuer des mots de passe de bases de données et des clés d'API sans date d'expiration.

Pour faire bouger le marché, Vercel impose des échéances strictes aux partenaires de son Marketplace : à partir du 30 novembre 2026, les éditeurs qui ne prennent pas en charge l'authentification OIDC de Vercel et s'appuient sur des secrets à longue durée de vie verront la mention « Not secure » apparaître dans leur fiche. À partir de janvier 2027, ces fournisseurs seront retirés du catalogue.

Pourquoi la clé statique pose problème maintenant

Un secret statique à longue durée de vie est une clé d'API ou un mot de passe que l'application réutilise en boucle, souvent sans date de péremption. Une telle clé peut fuiter dans un dépôt ou une messagerie, ou être volée via une dépendance compromise. Une nouvelle voie s'y ajoute : la prompt injection, qui pousse un agent à divulguer ses propres identifiants. Or les agents accèdent aux systèmes et aux données via des clés dont les droits dépassent souvent ce que requiert la tâche.

Chiffrer les secrets sur disque n'y change rien : un code malveillant en production lit les variables d'environnement exactement comme l'application elle-même. Tant que la clé n'a ni expiré ni été révoquée, n'importe qui peut l'utiliser. Et la rotation coûte cher. Selon Vercel, l'équipe a déjà mené plusieurs rotations douloureuses par précaution, pour des milliers d'heures d'ingénierie. L'entreprise ne veut pas recommencer.

Ce que Vercel propose à la place des clés

L'alternative est connue de longue date : OIDC. Un émetteur de confiance délivre un jeton signé à courte durée de vie qui identifie l'application. Le service destinataire le vérifie et décide quel accès accorder. Un jeton volé cesse de fonctionner une fois son délai écoulé. L'application obtient ses nouveaux jetons de façon programmatique : il n'y a donc ni clé permanente à distribuer ni clé à changer à la main.

La fédération OIDC est disponible sur Vercel depuis 2024 : les applications échangent les jetons de la plateforme contre des identifiants temporaires AWS, Google Cloud et Azure, selon des politiques de confiance configurées par projet et par environnement. L'entreprise étend désormais cette approche à ses propres services Blob, AI Gateway et Sandbox, ainsi qu'à l'API et à la CLI de Vercel, afin de supprimer les jetons à longue durée de vie des processus de déploiement.

Les nouveaux outils :

• OIDC UI — un registre de composants shadcn/ui avec un configurateur de trust-policy et un vérificateur de jetons côté serveur. Des formulaires prêts à l'emploi existent pour Vercel, GitHub, GitLab, Google, Bitbucket, AWS, Azure et des émetteurs OIDC quelconques.
• Vercel Connect — les applications et les agents demandent des jetons de fournisseurs au runtime, à partir de l'identité du déploiement. Dans le code, il suffit d'un appel à getToken en indiquant l'utilisateur et les scopes, par exemple pour accéder à Linear.
• Custom audience — le jeton est lié à un unique service destinataire.
• Exemple avec Azure — ClientAssertionCredential échange un jeton Vercel contre un accès à Cosmos DB, sans clé de base de données.

Latence et incitations

Vercel reconnaît qu'une clé statique a un avantage : elle se trouve déjà dans une variable d'environnement et ne requiert aucune requête réseau. L'obtention et l'échange de jetons ajoutent de la latence. Les fonctions Vercel reçoivent donc le jeton de la plateforme dans un en-tête de requête, et le SDK le lit sans appel supplémentaire. La plateforme réutilise les jetons non expirés, tandis que Vercel Connect met en cache les jetons de fournisseurs dans le processus et les renouvelle à l'approche de leur expiration. Les appels réseau ne subsistent que pour les custom audience et pour l'échange contre des jetons de fournisseurs.

Au-delà de la commodité et de la vitesse, Vercel cite un troisième obstacle : les éditeurs ont peu d'incitations à s'en occuper. C'est là que l'exemple de Chrome intervient : le navigateur a d'abord marqué HTTP comme « Not secure », puis fixé des échéances. Vercel compte suivre le même chemin et promet les mêmes exigences pour sa propre API et ses intégrations natives. L'entreprise veut en outre que les intégrations du Marketplace configurent automatiquement une authentification sécurisée lors de la connexion du service, sans étape distincte.

Ce que doivent faire développeurs et fournisseurs

Si vous développez un produit pour les clients de Vercel, vous devez décider d'ici le 30 novembre si vous acceptez directement les jetons OIDC ou si vous les échangez contre des identifiants temporaires. Les composants OIDC UI évitent d'écrire de zéro le formulaire de configuration de la confiance comme la vérification des jetons. Si vous utilisez simplement des services via le Marketplace, mieux vaut vérifier dès maintenant chez quels fournisseurs connectés vous stockez des clés permanentes dans des variables d'environnement, puis établir un plan de remplacement.

Pour les applications agentiques, le point de départ logique est Vercel Connect : un jeton propre à un utilisateur donné et à des scopes précis limite les dégâts en cas de prompt injection. Après la migration, les anciennes clés doivent être révoquées, et pas seulement abandonnées.