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 restreinte et suivez le guide de démarrage rapide. Choisissez les identifiants client OAuth lorsque votre politique de sécurité exige des jetons d’accès de courte durée ou lorsque 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. Aucun des deux identifiants 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 reporting, 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 nécessaire.
  • 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é à l’aide de 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 les clés API pour la création et la rotation.

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

Utilisez les identifiants client OAuth pour un service backend confidentiel lorsque votre organisation exige des jetons d’accès à durée limitée ou lorsqu’un outil d’intégration attend l’octroi client_credentials.
  1. Créez un client OAuth à portée restreinte pour le compte de service.
  2. Authentifiez le client auprès de votre point de terminaison de jetons régional à l’aide de 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 client doit toujours être stocké de manière sécurisée et faire l’objet d’une rotation ; les jetons de courte durée ne suppriment pas cette responsabilité. Les identifiants 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 contactez le support de Living Security au sujet de vos besoins. Consultez les identifiants client OAuth pour la création de clients, les secrets à affichage unique, la révocation et la récupération.

​
Conserver les identifiants sur votre backend

Les clés API de compte de service et les secrets 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 système de gestion de versions ou des journaux. Un identifiant de compte de service agit en tant que charge de travail ; il ne connecte pas une personne et ne fournit pas de flux de consentement 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 ni l’URL de la ressource, ni la version de l’API, ni les autorisations requises par une opération.