L’accès OAuth doit être activé pour votre organisation. Votre configuration fournit
le point de terminaison de jeton régional, l’émetteur, l’audience et la méthode d’authentification du client.
Si vous avez besoin de ces paramètres ou si vous ne pouvez pas accéder à la gestion des clients, communiquez avec
le soutien de Living Security.
Avant de commencer
- Créez un compte de service disposant uniquement des autorisations dont l’intégration a besoin.
- Utilisez un identifiant de gestion avec
service_account:manageet chaque autorisation que vous souhaitez accorder au nouveau client. Le compte cible doit également détenir ces autorisations. Un client ne peut étendre les pouvoirs d’aucun des deux comptes. - Choisissez la région de l’organisation. Les identifiants d’API et les jetons d’accès OAuth doivent être utilisés avec l’hôte d’API régional correspondant.
- Conservez le secret du client et les jetons dans votre espace de stockage de secrets côté serveur. Ne les placez jamais dans le code d’un navigateur, dans des applications mobiles, dans le contrôle de code source ni dans les journaux de requêtes.
Créer un client
POST /v1/oauth_clients exige service_account_id, une liste non vide de
scopes explicites, et un Idempotency-Key. Les caractères génériques ne sont pas acceptés. Un client prend en charge
jusqu’à 100 portées, d’une longueur combinée maximale de 4 096 caractères. Chaque compte de
service peut avoir au plus 20 clients ou opérations de création ou de nettoyage non résolues.
La révocation refuse immédiatement l’accès à l’API. Un client ou une création incertaine auprès du fournisseur
continue de compter dans la limite jusqu’à ce que le nettoyage à distance soit confirmé.
Une réservation abandonnée ou une création dont l’échec est avéré avant le début du travail
du fournisseur peut libérer son emplacement en toute sécurité. Sa clé de nouvelle tentative appartient toujours à la tentative
d’origine; récupérez ce reçu avant de décider de créer un remplacement.
Choisissez une clé de nouvelle tentative pour cette tentative de création et conservez-la avant d’envoyer
la requête. Utilisez de 1 à 255 caractères ASCII visibles, sans espaces. Réutilisez-la avec
le même compte, les mêmes portées, le même principal de gestion, la même région et la même version d’API après une
perte de réponse. Le renouvellement de l’identifiant de gestion sous le même compte de service
ne crée pas une nouvelle identité de nouvelle tentative.
Installez le paquet requests de Python. Chargez les valeurs d’environnement suivantes au moyen
de votre gestion habituelle des secrets et de la configuration :
Python
201 et contiennent une ressource oauth_client
avec id, service_account_id, client_id, scopes, status, created_at et
client_secret. Les réponses sont marquées Cache-Control: no-store.
ididentifie la ressource de la plateforme. Enregistrez-le pour la récupération et la révocation.client_ididentifie le client lors de l’échange de jetons. Il ne s’agit pas de l’ID de ressource de la plateforme. Il peut êtrenullpendant que la création est en attente.client_secretest renvoyé uniquement à la requête qui termine la création. Chaque requête de création répétée renvoienull, y compris une nouvelle tentative après une réponse de réussite perdue. La récupération ne renvoie jamais de secret.
Reprendre après une réponse perdue ou interrompue
Répétez la même requête de création avec la clé de nouvelle tentative enregistrée pour récupérer un reçu de ressource. Le reçu reflète l’état actuel; un client révoqué reste donc révoqué. Cette opération n’utilise pas le contrat général de relecture de réponse en cache de 24 heures et ne renvoie pas d’en-têteIdempotent-Replayed.
Consultez erreurs pour les ID de requête et les détails de reprise.
N’envoyez jamais un secret de client ni un jeton d’accès avec une demande de soutien.
Consulter et révoquer
Utilisez votre identifiant de gestion et la ressource de la plateformeid :
La révocation bloque les requêtes d’API subséquentes du client, y compris celles qui utilisent
des jetons déjà émis. Elle n’annule pas le travail déjà accepté par l’API.
Le nettoyage à distance des identifiants peut se terminer plus tard. Il est sûr de répéter la révocation, qui
n’exige aucune clé de nouvelle tentative. Continuez à utiliser l’identifiant de gestion si le client
en cours de révocation est lui-même un appelant de l’API.

