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, contactez
l’assistance de Living Security.
Avant de commencer
- Créez un compte de service disposant uniquement des autorisations nécessaires à l’intégration.
- Utilisez un identifiant de gestion disposant de
service_account:manageet de chaque autorisation que vous souhaitez accorder au nouveau client. Le compte cible doit également détenir ces autorisations. Un client ne peut étendre les droits 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 sur l’hôte d’API régional correspondant.
- Conservez le secret du client et les jetons dans votre stockage de secrets côté serveur. Ne les placez jamais dans du code de navigateur, des applications mobiles, un système de contrôle de version ou des journaux de requêtes.
Créer un client
POST /v1/oauth_clients requiert 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 cumulée maximale de 4 096 caractères. Chaque compte de service
peut avoir au plus 20 clients ou opérations de création/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 avant tout traitement par le fournisseur est avéré
peut libérer son emplacement en toute sécurité. Sa clé de nouvelle tentative reste associée à la tentative initiale ;
récupérez ce reçu avant de décider de créer un remplaçant.
Choisissez une clé de nouvelle tentative pour cette tentative de création et conservez-la de façon persistante 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
réponse perdue. Renouveler l’identifiant de gestion sous le même compte de service
ne crée pas de nouvelle identité de nouvelle tentative.
Installez le package Python requests. Chargez les valeurs d’environnement suivantes via
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 valoirnulltant que la création est en attente.client_secretn’est renvoyé qu’à la requête qui finalise la création. Toute requête de création répétée renvoienull, y compris une nouvelle tentative après une réponse de succès 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 de secret client ni de jeton d’accès avec une demande d’assistance.
Inspecter et révoquer
Utilisez votre identifiant de gestion et la ressource de la plateformeid :
La révocation bloque les requêtes d’API ultérieures du client, y compris celles effectuées avec des
jetons déjà émis. Elle n’annule pas le travail déjà accepté par l’API.
Le nettoyage distant des identifiants peut se terminer ultérieurement. Répéter la révocation est sans risque
et ne nécessite aucune clé de nouvelle tentative. Continuez à utiliser l’identifiant de gestion si le client
révoqué est lui-même un appelant de l’API.

