Tokens Bearer
Format des tokens Bearer, modèle de stockage SHA-256, TTL, chemin de validation, rotation, révocation et format du header Authorization pour VantagePeers.
Tokens Bearer
Les tokens Bearer sont les identifiants principaux pour tous les appels au serveur MCP VantagePeers. Cette page couvre le format des tokens, le modèle de sécurité, le chemin de validation et comment effectuer une rotation ou une révocation.
Format du token
Un token Bearer VP est une chaîne hexadécimale minuscule de 64 caractères générée à partir de 32 octets cryptographiquement aléatoires :
a1b2c3d4e5f67890abcdef1234567890abcdef1234567890abcdef1234567890Génération :
const rawBytes = new Uint8Array(32)
crypto.getRandomValues(rawBytes)
const bearer = Array.from(rawBytes).map(b => b.toString(16).padStart(2, '0')).join('')Modèle de stockage
Le token Bearer brut n'est jamais stocké dans Convex. Seul son hash SHA-256 est persisté. Le token est retourné à l'appelant exactement une fois lors de l'émission. S'il est perdu, il ne peut pas être récupéré — révoquez et réémettez-en un nouveau.
À l'émission :
- 32 octets aléatoires sont générés.
sha256(token_brut)est calculé sous forme de chaîne hex 64 caractères.- Le hash est écrit dans
userBearerTokens.tokenHash(flux Clerk) ouoauth_access_tokens.tokenHash(flux OAuth). - Le token brut est retourné dans le corps de la réponse HTTP et supprimé côté serveur.
Durée de vie des tokens
| Type de token | TTL par défaut | Configurable ? |
|---|---|---|
| Émis par Clerk (niveau utilisateur) | TTL_7_DAYS (7 × 24 × 60 × 60 × 1000 ms) | Non — codé en dur dans credentials.ts |
| Token d'accès OAuth | Configurable par l'admin | Oui — défini à l'appel createAccessToken |
BEARER_SECRET_MASTER | Sans expiration | Rotation manuelle via mise à jour de la variable d'env |
Chemin de validation
Quand le serveur MCP reçoit une requête avec Authorization: Bearer <token> :
- La valeur brute du token est extraite du header.
sha256(token)est calculé.- Le hash est recherché dans Convex via l'index
by_token_hashsuruserBearerTokens(tokens Clerk) ouby_tokenHashsuroauth_access_tokens(tokens OAuth). - Si trouvé : vérification du flag
revokedet de l'horodatageexpiresAt. - Si tous les contrôles passent : la requête est autorisée.
Référence source : mcp-server/src/auth.ts:275 — recherche Bearer sha256 via l'index by_token_hash.
Le token BEARER_SECRET_MASTER suit un chemin plus simple : comparaison de chaîne en temps constant contre la valeur de la variable d'environnement (sans accès base de données).
Format du header
Toutes les requêtes au serveur MCP doivent inclure :
Authorization: Bearer <token-hex-64-chars>Exemple :
GET /health HTTP/1.1
Host: votre-déploiement.railway.app
Authorization: Bearer a1b2c3d4e5f67890abcdef1234567890abcdef1234567890abcdef1234567890Pour la configuration .mcp.json de Claude Code :
{
"mcpServers": {
"vantage-peers": {
"type": "http",
"url": "https://votre-déploiement.railway.app/mcp",
"headers": {
"Authorization": "Bearer votre-secret-bearer"
}
}
}
}BEARER_SECRET_MASTER
BEARER_SECRET_MASTER est le token master admin. Il :
- Est défini comme variable d'environnement sur le serveur MCP (variables d'env Railway ou équivalent)
- Sert aux opérations admin : provisionnement de clients OAuth, contrôle d'émission de tokens, mutations admin Convex
- Est validé par comparaison en temps constant (sans accès base de données) pour prévenir les attaques temporelles
- Est requis pour toutes les mutations admin de
oauth.ts(createClient,listClients,deleteClient,seedDefaultProfiles)
BEARER_SECRET_MASTER octroie un accès admin complet. Ne l'exposez jamais dans du code côté client, des extensions navigateur ou le contrôle de version. Utilisez plutôt le flux d'échange JWT Clerk pour émettre des tokens utilisateur à portée limitée.
Procédure de rotation de BEARER_SECRET_MASTER
- Générez un nouveau secret :
openssl rand -hex 32 - Mettez à jour
BEARER_SECRET_MASTERdans les variables d'environnement Railway (ou votre hôte MCP). - Redémarrez le processus MCP pour prendre en compte la nouvelle valeur.
- Mettez à jour les comptes de service ou automatisations qui utilisent le token master.
- L'ancienne valeur est immédiatement invalide une fois la variable d'env mise à jour et le processus redémarré.
Révoquer un token émis par Clerk
Il n'existe pas d'endpoint API pour révoquer des tokens individuels émis par Clerk en V0.0.2. Pour révoquer :
- Contactez votre admin VP ou utilisez le tableau de bord Convex pour mettre directement
userBearerTokens.revoked = truepour letokenHashcorrespondant. - Le token échouera à la validation à la prochaine requête une fois
revoked: true.
Un endpoint de révocation est prévu pour V0.0.3.
Révoquer un token OAuth
Les tokens OAuth sont révoqués via la mutation deleteClient dans oauth.ts, qui définit revokedAt sur l'enregistrement client et tous les tokens d'accès/rafraîchissement associés :
// Appel admin — requiert BEARER_SECRET_MASTER
oauth.deleteClient({ callerToken: masterToken, clientId: 'votre-client-id' })Cela révoque le client et tous ses tokens atomiquement. Le client doit se ré-enregistrer via DCR pour obtenir de nouveaux identifiants.
Sources d'émission des tokens
| Source | Table | Index |
|---|---|---|
Échange JWT Clerk (credentials.ts) | userBearerTokens | by_token_hash |
DCR OAuth + octroi de token (oauth.ts) | oauth_access_tokens | by_tokenHash |
| Token master | Variable d'environnement uniquement | N/A |