Ouvrir un accès programmatique

Une clé API sert à laisser entrer autre chose que vous : un script, un outil interne, une intégration.

Une clé n'a pas de droits à elle

C'est le point qui surprend, et c'est celui qui protège.

Une clé est rattachée à une identité de votre espace, et elle hérite de ses droits. Elle ne porte pas ses propres permissions.

Conséquence directe : pour donner un accès restreint à un outil, on ne bride pas la clé, on la rattache à une identité restreinte. Un intégrateur qui doit seulement lire les contrats reçoit une clé liée à une identité en lecture seule sur les contrats.

Le secret ne s'affiche qu'une fois

À la création, la clé s'affiche. Après, plus jamais.

Rangez-la dans votre gestionnaire de secrets dans la foulée, pas dans un message ni dans un fichier de notes.

Refermer

Une clé se révoque, et l'accès s'arrête. Trois moments où c'est le bon réflexe.

• Un prestataire termine sa mission.
• Une clé a pu se retrouver dans un dépôt de code, un ticket ou une capture d'écran.
• Une intégration est remplacée par une autre.

Révoquer coûte cinq secondes. Se demander pendant six mois si une clé traîne quelque part coûte beaucoup plus.

Bonnes habitudes

Une clé par usage. Le script d'import et l'outil de reporting ont chacun la leur, sinon révoquer l'une casse l'autre.

Une date de fin quand elle est connue. Une clé de prestataire expire à la fin de la mission, sans dépendre du fait que quelqu'un y repense.

Jamais dans le navigateur. Une clé s'utilise depuis un serveur. Placée dans du code qui tourne chez vos visiteurs, elle est publique le jour même.