Vos jetons n'expirent jamais, c'est le problème

Ce qui se passe

Vercel Connect passe en disponibilité générale, avec plus de 100 connecteurs vers des services tiers. Le principe : votre application ne stocke plus aucun identifiant de fournisseur, elle en demande un à l'exécution.

L'argument d'ouverture mérite d'être cité, parce qu'il vaut bien au-delà de Vercel : mettre un jeton permanent dans un coffre-fort le rend plus difficile à voler, pas moins dangereux une fois volé. Il n'expire toujours pas, et aucun coffre ne limite ce qu'un identifiant fuité peut faire.

Le problème, posé correctement

Gérer des identifiants est devenu un travail à part entière : scripts de rotation, secrets recopiés d'un environnement à l'autre, jetons partagés entre collègues. Les agents ont aggravé la situation — ils touchent plus de systèmes, avec plus d'autonomie, plus souvent — alors que les outils pour contenir un secret n'ont pas bougé.

Le tableau que dresse le billet résume l'écart entre un jeton stocké et un jeton demandé :

Comment ça marche

On enregistre une fois un connecteur pour un fournisseur — Slack, GitHub, Snowflake, Shopify, ou son propre service OAuth —, on l'attache aux projets et environnements concernés, et le code réclame un jeton au moment de s'en servir :

vercel connect create slack --name acme-slack

import { getToken } from '@vercel/connect';

const token = await getToken('slack/acme-slack', {
  subject: { type: 'app' },
});

Le point important est ce qui prouve l'identité du demandeur. Ce n'est pas un secret de plus : chaque déploiement Vercel porte une identité OIDC, et le SDK s'en sert. Autrement dit, il n'y a pas de « secret pour aller chercher les secrets » — ce qui est exactement le problème que ce genre de dispositif rate souvent.

Deux granularités s'ajoutent :

• Par requête. Une étape d'un agent lit un dépôt, la suivante ouvre une issue : chacune demande uniquement ce dont elle a besoin. Sur GitHub, un jeton peut être restreint à un seul dépôt en lecture seule, au lieu d'une autorisation permanente à l'échelle de l'organisation.
• Par identité. Le jeton agit comme l'application par défaut, mais en passant un utilisateur nommé comme sujet, il agit en son nom, limité à ce qu'il a autorisé lors d'un consentement unique.

Ce que ça change, et ce que ça ne change pas

La limite est franche : la finesse réelle dépend du service en face. GitHub est l'exemple le plus favorable ; tous les fournisseurs n'offrent pas ce niveau de découpage, et un connecteur ne peut pas inventer une granularité que l'API distante ne propose pas.

L'autre limite est l'adhérence : le mécanisme repose sur l'identité OIDC des déploiements Vercel. Hors de cette plateforme, ce n'est pas transposable tel quel.

En revanche, le patron l'est. La même idée existe avec les rôles IAM et AssumeRoleWithWebIdentity sur AWS, avec Workload Identity Federation sur GCP, avec les jetons OIDC de GitHub Actions. Le point commun : la machine prouve ce qu'elle est au lieu de présenter ce qu'elle détient.

À retenir

Si vous avez des jetons de fournisseur dans vos variables d'environnement — et c'est le cas de presque tout le monde —, la question à se poser n'est pas « sont- ils bien rangés » mais « combien de temps vivent-ils, et que couvrent-ils ». Le meilleur secret reste celui que votre application ne détient pas.

Source : Vercel