veilletech.frCe qui se passe
Vercel KMS déporte la signature hors de votre application : vos Vercel Functions demandent un JWT signé au service, elles ne détiennent aucune clé.
L'authentification passe par le token OIDC de la fonction ; la clé privée ne quitte jamais le KMS, et seuls les vérificateurs ont besoin de la partie publique.
Ce que vous pouvez faire
- Créer et faire tourner issuers et clés de signature — RSA, ECDSA, EdDSA — depuis la CLI ou le dashboard.
- Accorder l'accès à la signature par projet et par environnement : production, preview, développement, environnements personnalisés.
- Contraindre, par autorisation, les claims qu'un projet peut demander, et valider les claims d'un token au regard d'un JSON Schema.
- Signer des JWT avec des claims personnalisées et un TTL configurable, ou signer des octets bruts, via le paquet
@vercel/kms.
Vérification sans code spécifique
Chaque issuer publie automatiquement un document OpenID Connect Discovery et un JWK set. Les tokens sont donc vérifiables par n'importe quelle bibliothèque OIDC ou JOSE standard, sans code propre à Vercel.
Pourquoi c'est un vrai gain
Une clé privée dans une variable d'environnement est un secret qui fuite par les logs, les dumps de configuration et les captures d'écran. La retirer de l'application supprime une classe entière d'incidents, et la rotation devient une opération d'infrastructure plutôt qu'un redéploiement.
Recommandation du changelog : créer un issuer distinct par projet et par environnement, afin qu'une rotation ou une révocation n'affecte qu'un périmètre. Prérequis : Vercel CLI 59.1.0.
La réserve
Vercel KMS est en bêta, disponible sur tous les plans. Vercel prévient que les fonctionnalités et le comportement peuvent changer avant la disponibilité générale — à intégrer au calcul avant d'en faire le point de passage de vos tokens de production.