Authentification

Chaque requête porte une clé d’API dans l’en-tête Authorization :

Authorization: Bearer $OPENLATCH_API_KEY

Clés d’API

Une clé personnelle appartient à la personne qui l’a créée et agit avec le rôle actuel de cette personne. Une clé d’organisation appartient à l’organisation : elle agit en son propre nom, avec le rôle admin, et continue de fonctionner quand son créateur part. Chaque changement fait avec une clé enregistre la clé comme acteur, et le journal d’audit nomme la personne via la clé pour une clé personnelle, et le nom de la clé pour une clé d’organisation. Créez et gérez les clés dans la console ; voir Gérer les clés d’API.

Rôle	Peut
viewer	Lire les ressources et la configuration
editor	Tout ce que peut un viewer, plus gérer les ressources et la configuration, comme les politiques d’intention, les zones et la propriété des agents
admin	Tout ce que peut un editor, plus les utilisateurs, les équipes et les réglages
owner	Tout ce que peut un admin, plus l’organisation elle-même

Chaque page d’opération indique son rôle minimum. Une requête sans clé valide, ou avec une clé expirée ou révoquée, est refusée avec UNAUTHORIZED. Une requête d’un rôle inférieur au minimum de l’opération est refusée avec FORBIDDEN.

Agents

Un agent connecté au serveur MCP se connecte avec OAuth au nom de la personne qui l’utilise, et agit avec le rôle de celle-ci. Son jeton ne fonctionne qu’à travers le serveur MCP : envoyé directement à l’API, il est refusé. Voir Utiliser OpenLatch depuis votre agent.

Ce que peut faire une clé

Une clé n’atteint une opération que si ses portées et son rôle le permettent tous les deux. Chaque page d’opération indique la portée qu’elle exige à côté de son rôle minimum, et Portées des clés d’API liste chaque portée.

Clé	Ce qu’elle peut faire
Full access (legacy)	Tout ce que permet le rôle de sa personne. Seule une clé qui existait avant les portées a un accès complet, et aucune nouvelle ne peut être créée
Clé personnelle à portées	Seulement les opérations des portées qu’elle détient, dans les limites du rôle de sa personne. Une portée qui modifie quelque chose accorde aussi de le lire, et toute clé peut lire son organisation et se révoquer elle-même
Clé d’organisation à portées	Seulement les opérations des portées qu’elle détient, avec le rôle admin. Toute opération d’administration de l’organisation lui est refusée quelles que soient ses portées, et une opération qui décrit une personne lui répond FORBIDDEN

Une clé à portées qui appelle une opération hors de ses portées est refusée avec INSUFFICIENT_SCOPE avant que son rôle soit vérifié. Le refus nomme la portée manquante et renvoie vers la référence des portées. Créez une clé à portées comme le décrit Gérer les clés d’API.

Une clé à accès complet divulguée agit avec le rôle complet de sa personne jusqu’à sa révocation. Réduisez ce risque : restreignez chaque clé à accès complet, donnez à chaque intégration une clé qui ne détient que les portées dont elle a besoin, gardez les clés dans un coffre de secrets et révoquez une clé dès que plus rien ne l’utilise.