Vercel KMS ajoute la signature de JWT depuis les Functions sans exposer la clé privée

Vercel présente Vercel KMS comme un service de managed asymmetric signing keys (clés asymétriques gérées) pour signer des JWT et des messages depuis ses Functions (fonctions serveur), avec une règle simple : la clé privée ne quitte jamais le service de gestion de clés. La Function s’authentifie avec un Vercel OIDC token (jeton d’identité Vercel), tandis que les vérificateurs n’utilisent que la clé publique exposée par l’émetteur. (vercel.com)

Ce que l’éditeur ajoute concrètement

Le changelog liste quatre capacités utiles au quotidien :

• création et rotation d’issuers (émetteurs) et de clés de signature en RSA, ECDSA et EdDSA depuis la console ou la CLI (ligne de commande) ;
• signature de JWT avec des claims (revendications, c’est-à-dire des champs de contexte comme sub ou scope) personnalisés et une TTL (time to live, durée de validité) configurable ;
• gestion de l’accès à la signature par projet et par environnement : production, preview, développement et environnements personnalisés ;
• contrôle des claims autorisés par grant (autorisation) et validation possible via JSON Schema (schéma de validation JSON). (vercel.com)

Vérification standard, sans code spécifique Vercel

Vercel documente aussi un point important pour l’interopérabilité : chaque issuer publie un document de découverte OpenID Connect et un fichier JWKS public, accessible à des URL dédiées. L’idée est que n’importe quelle bibliothèque standard OIDC ou JOSE (suite de bibliothèques pour JWT/JWS/JWE) peut vérifier le token, sans code propriétaire. Le changelog donne un exemple avec jose : createRemoteJWKSet(...) puis jwtVerify(...). (vercel.com)

import { createRemoteJWKSet, jwtVerify } from 'jose';

const issuer = 'https://kms.vercel.com/123e4567-e89b-42d3-a456-426614174000';
const jwks = createRemoteJWKSet(new URL(`${issuer}/jwks.json`));

const { payload } = await jwtVerify(token, jwks, { issuer });

Ce qui change pour une équipe TypeScript ou Node.js

Le cas d’usage visé est clair : une Function peut produire un jeton court, le transmettre en Bearer (jeton présenté dans l’en-tête Authorization), puis laisser une API descendante le vérifier avec la clé publique. Vercel montre aussi une commande CLI pour créer un issuer et ouvrir l’accès à un projet : vercel kms add ... puis vercel kms add-grant .... La CLI Vercel requise est 59.1.0 ou plus récente. (vercel.com)

En pratique, l’intérêt est surtout opérationnel : on évite de stocker une clé privée dans le dépôt, dans les secrets du projet ou dans l’environnement d’exécution, et on garde une séparation nette entre l’éditeur du jeton et le vérificateur. Vercel recommande en plus de créer un issuer distinct par projet et par environnement, afin de limiter l’impact d’une rotation ou d’une révocation de clé à un seul périmètre. Le service est annoncé en bêta, disponible sur tous les plans, avec des comportements susceptibles d’évoluer avant la disponibilité générale. (vercel.com)