Ce que vous allez faire
- Effectuer la rotation d'une clé sans interruption de service en émettant d'abord le remplacement et en ne révoquant l'ancienne clé qu'après confirmation que la nouvelle est active.
- Révoquer immédiatement une clé compromise — la propagation vers toutes les régions prend au plus 60 secondes.
- Stocker les clés dans des variables d'environnement ou un gestionnaire de secrets, jamais dans le code, et les faire pivoter quand un membre ayant accès quitte l'équipe.
Les clés API sont des jetons bearer de longue durée, il est donc essentiel de procéder à leur rotation de manière planifiée — et de les révoquer immédiatement en cas de fuite. Cet article détaille ces deux situations.
Rotation d'une clé sans interruption de service#
La rotation consiste à émettre une nouvelle clé avant de retirer l'ancienne, afin d'éviter toute interruption de l'authentification de votre intégration.
- Allez dans Settings → API keys et cliquez sur Generate key.
- Donnez à la nouvelle clé un nom explicite (par exemple
production-v2). - Choisissez le même rôle que celui de la clé que vous remplacez.
- Copiez le jeton — il n'est affiché qu'une seule fois.
- Mettez à jour votre variable d'environnement ou votre gestionnaire de secrets avec le nouveau jeton et déployez.
- Une fois que la nouvelle clé est active et confirmée (vérifiez la colonne Last used — elle devrait changer en quelques minutes), retournez dans Settings → API keys et cliquez sur Revoke sur l'ancienne clé.
Maintenez l'ancienne clé active jusqu'à ce que vous soyez certain que la nouvelle fonctionne. Si vous la révoquez trop tôt alors que le déploiement n'est pas terminé, le trafic rencontrera des erreurs 401.
Révocation immédiate d'une clé compromise#
Si une clé est exposée — poussée sur un dépôt public, divulguée dans des logs, incluse dans un bundle côté client — révoquez-la d'abord, enquêtez ensuite.
- Settings → API keys, trouvez la clé par son nom ou son préfixe (le préfixe est visible dans le tableau même si le jeton complet ne l'est pas).
- Cliquez sur Revoke. La révocation se propage à toutes les régions en moins de 60 secondes.
- Émettez une clé de remplacement et mettez à jour vos secrets.
- Vérifiez l'horodatage Last used sur la clé révoquée pour estimer la durée de l'exposition et déterminer si vous devez auditer toute activité suspecte.
Les clés révoquées sont conservées dans le tableau avec un badge revoked pour vos archives. Elles ne peuvent pas être réactivées.
Mise à jour sécurisée des secrets#
La pratique standard consiste à stocker les clés dans des variables d'environnement, et non dans le code :
# .env.local (never committed)
ELIDO_API_KEY=elido_live_xxx...
import { ElidoClient } from "@elido/sdk";
const client = new ElidoClient({ apiKey: process.env.ELIDO_API_KEY! });
Pour les pipelines CI, utilisez le coffre-fort de secrets de votre plateforme (secrets GitHub Actions, variables GitLab CI, etc.) et effectuez une rotation dès qu'un membre ayant accès quitte l'équipe.
Ce qu'il advient des intégrations en direct#
Lorsque vous révoquez une clé, toute requête en cours ayant déjà envoyé le jeton ira jusqu'à son terme — nous validons au début de la requête, pas en cours de réponse. Les requêtes débutant après la révocation renvoient un code 401 Unauthorized. Les SDKs ne retentissent pas sur un 401 (cela créerait une boucle), votre intégration commencera donc à échouer immédiatement.
Prévoyez une courte période de chevauchement : gardez l'ancienne clé active jusqu'à ce que vous ayez confirmé que la nouvelle est opérationnelle en production.
Dépannage#
401 sur une clé que je viens de créer. Le jeton affiché lors de la création est la clé complète incluant le suffixe secret. Si vous n'avez copié que le préfixe depuis le tableau (par exemple elido_abc123), cela ne fonctionnera pas — le préfixe est uniquement destiné à l'affichage. Générez une nouvelle clé et copiez le jeton complet.
Le bouton Revoke est absent. La clé est probablement déjà révoquée. Les clés révoquées affichent un badge revoked et aucun bouton d'action. Vérifiez que vous consultez le bon espace de travail — les clés sont workspace-scoped.
Délai de propagation de 60 secondes. Si vous avez révoqué une clé et que les requêtes réussissent encore pendant un court instant, c'est normal. Nos nœuds edge synchronisent la révocation via Redis pub/sub ; le délai maximal constaté est d'environ 60 secondes.
La clé a disparu de la liste. Nous conservons indéfiniment les clés révoquées dans le tableau à des fins d'audit. Si vous ne la trouvez pas, vérifiez que vous n'avez pas filtré la liste — il n'y a pas de filtre "clés actives uniquement" par défaut, mais une recherche textuelle sur le champ du nom masquera les lignes ne correspondant pas.