Skip to main content
Vous n’avez pas besoin d’OAuth pour utiliser l’API publique. Pour une intégration privée côté serveur, commencez par une clé API à portée limitée et suivez le guide de démarrage rapide. Choisissez les informations d’identification client OAuth lorsque votre politique de sécurité exige des jetons d’accès de courte durée ou que votre plateforme d’intégration prend déjà en charge ce flux. Les deux options utilisent un compte de service. Un compte de service est l’identité de l’intégration, et non une troisième méthode d’authentification.

​
Comment les éléments s’articulent

Créez un compte de service par intégration. Choisissez une clé API ou un client OAuth pour ce compte; vous n’avez pas besoin des deux méthodes pour chaque requête API. Aucune des deux informations d’identification ne peut dépasser les autorisations actuelles du compte. Le guide de démarrage rapide utilise l’authentification Basic. Un en-tête Bearer est également pris en charge pour les clés API; l’utilisation de cet en-tête ne signifie pas que vous avez besoin d’un client OAuth.

​
Choisir une clé API pour une intégration simple

Utilisez une clé API pour vos propres tâches planifiées, scripts de production de rapports, pipelines de données ou autres services backend lorsqu’un secret stocké dans votre gestionnaire de secrets répond à vos exigences de sécurité.
  • Effectuez des requêtes authentifiées directement; aucun échange de jeton n’est requis.
  • Sélectionnez uniquement les autorisations dont la charge de travail a besoin et définissez une date d’expiration.
  • Effectuez la rotation de la clé en utilisant sa période de chevauchement, ou révoquez-la immédiatement en cas d’exposition.
Une intégration par clé API n’a pas besoin de client OAuth. Commencez par le guide de démarrage rapide, puis consultez Clés API pour la création et la rotation.

​
Choisir OAuth pour des jetons d’accès de courte durée

Utilisez les informations d’identification client OAuth pour un service backend confidentiel lorsque votre organisation exige des jetons d’accès à durée de vie limitée ou qu’un outil d’intégration attend l’octroi client_credentials.
  1. Créez un client OAuth à portée limitée pour le compte de service.
  2. Authentifiez le client auprès du point de terminaison de jetons de votre région en utilisant la méthode d’authentification client fournie lors de la configuration.
  3. Envoyez le jeton d’accès obtenu avec vos requêtes API. Obtenez un nouveau jeton avant l’expiration du jeton actuel.
OAuth ajoute à votre intégration l’obtention des jetons et la gestion de leur expiration. Le secret du client doit tout de même être stocké de façon sécurisée et faire l’objet d’une rotation; les jetons de courte durée n’éliminent pas cette responsabilité. Les informations d’identification client n’utilisent pas de jetons d’actualisation : authentifiez à nouveau le client pour obtenir un nouveau jeton d’accès. L’accès OAuth doit être activé pour votre organisation. S’il ne l’est pas, utilisez une clé API ou communiquez avec le soutien de Living Security au sujet de vos besoins. Consultez Informations d’identification client OAuth pour la création de clients, les secrets à usage unique, la révocation et la récupération.

​
Conserver les informations d’identification sur votre backend

Les clés API de compte de service et les secrets de client OAuth doivent être conservés dans un stockage de secrets côté serveur. Ne les placez pas dans du code de navigateur, des applications mobiles, un contrôle de source ni des journaux. Une information d’identification de compte de service agit en tant que charge de travail; elle ne connecte pas une personne et ne fournit pas de flux de consentement du client. Utilisez l’hôte d’API régional de votre organisation avec l’une ou l’autre méthode. Changer de méthode d’authentification ne modifie pas l’URL de la ressource, la version de l’API ni les autorisations qu’exige une opération.