Autorisation pour l'API Tag Manager

Ce document décrit comment une application peut obtenir l'autorisation d'envoyer des requêtes à l'API Tag Manager.

Autoriser les requêtes

Pour que les utilisateurs puissent afficher les informations de leur compte sur un site Google, ils doivent d'abord se connecter à un compte Google. De la même manière, lorsque les utilisateurs accèdent pour la première fois à votre application, ils doivent l'autoriser à accéder à leurs données.

Chaque demande envoyée par votre application à l'API Tag Manager doit inclure un jeton d'autorisation. Celui-ci permet également d'identifier votre application auprès de Google.

À propos des protocoles d'autorisation

Votre application doit autoriser les requêtes via le protocole OAuth 2.0. Les autres protocoles d'autorisation ne sont pas acceptés. Si votre application utilise la fonctionnalité Se connecter avec Google, certains aspects de l'autorisation sont traités pour vous.

Autoriser des requêtes avec OAuth 2.0

Toutes les requêtes adressées à l'API Tag Manager doivent être autorisées par un utilisateur authentifié.

Les détails de la procédure d'autorisation (ou "flux") concernant OAuth 2.0 varient légèrement selon le type d'application que vous développez. La procédure générale suivante s'applique à tous les types d'applications :

  1. Lorsque vous créez votre application, vous l'enregistrez dans la console d'API Google. Google fournit ensuite des informations dont vous aurez besoin ultérieurement, dont un ID client et un code secret du client.
  2. Activez l'API Tag Manager dans la console Google APIs. Si l'API ne figure pas dans la console, ignorez cette étape.
  3. Lorsque votre application doit accéder à des données utilisateur, elle demande à Google un champ d'application d'accès particulier.
  4. Google affiche alors un écran d'autorisation, dans lequel l'utilisateur est invité à autoriser votre application à demander certaines de ses données.
  5. Si l'utilisateur accepte, Google attribue à votre application un jeton d'accès temporaire.
  6. Votre application demande des données utilisateur en joignant le jeton d'accès à la requête.
  7. Dès lors que Google valide la requête et le jeton, les données demandées sont renvoyées.

Certains flux comportent d'autres étapes, comme l'utilisation de jetons d'actualisation afin d'obtenir de nouveaux jetons d'accès. Pour en savoir plus sur les flux concernant divers types d'applications, consultez la documentation OAuth 2.0 de Google.

Voici les informations sur le champ d'application d'OAuth 2.0 pour l'API Tag Manager:

Définition du champ d'application Signification
https://www.googleapis.com/auth/tagmanager.readonly Affichez vos conteneurs Google Tag Manager.
https://www.googleapis.com/auth/tagmanager.edit.containers Gérer vos conteneurs Google Tag Manager
https://www.googleapis.com/auth/tagmanager.delete.containers Supprimez vos conteneurs Google Tag Manager.
https://www.googleapis.com/auth/tagmanager.edit.containerversions Gérer les versions de vos conteneurs Google Tag Manager
https://www.googleapis.com/auth/tagmanager.publish Publiez vos conteneurs Google Tag Manager.
https://www.googleapis.com/auth/tagmanager.manage.users Gérez les autorisations des utilisateurs de vos données Google Tag Manager.
https://www.googleapis.com/auth/tagmanager.manage.accounts Gérez vos comptes Google Tag Manager.

Pour demander l'accès via OAuth 2.0, vous avez besoin du champ d'application ainsi que des informations fournies par Google lors de l'enregistrement de l'application (l'ID client et le code secret du client, par exemple).

Getting Started

Pour commencer à utiliser l'API Tag Manager, vous devez d'abord utiliser l'outil de configuration, qui vous aide à créer un projet dans la console Google APIs, à activer l'API et à créer des identifiants.

Pour configurer un nouveau compte de service, procédez comme suit:

  1. Cliquez sur Créer des identifiants > Clé de compte de service.
  2. Choisissez de télécharger la clé publique/privée du compte de service sous forme de fichier P12 standard ou de fichier JSON pouvant être chargé par une bibliothèque cliente de l'API Google.

Votre nouvelle paire de clés publique et privée est générée et téléchargée sur votre ordinateur. Il s'agit de la seule copie de cette clé. Il vous incombe de le stocker en toute sécurité.

Flux OAuth 2.0 courants

Les consignes suivantes décrivent des cas d'utilisation courants pour des flux OAuth 2.0 spécifiques:

Serveur Web

Ce flux est adapté pour l'accès automatisé/hors connexion/planifié au compte Google Tag Manager d'un utilisateur.

Exemple :
  • Mettre à jour automatiquement les informations Tag Manager à partir d'un serveur

Côté client

Idéal lorsque les utilisateurs interagissent directement avec l'application pour accéder à leur compte Google Tag Manager dans un navigateur. Ce flux élimine le besoin de fonctionnalités côté serveur, mais il rend également peu pratique la création de rapports automatisés/hors connexion/planifiés.

Exemple :
  • Outil de configuration personnalisé basé sur un navigateur.

Applis installées

Pour les applications distribuées en tant que package et installées par l'utilisateur. Elle nécessite que l'application ou l'utilisateur ait accès à un navigateur pour effectuer le flux d'authentification.

Exemples :
  • Un widget pour le bureau sur PC ou Mac.
  • Plug-in pour un système de gestion de contenu. L'avantage de ce flux par rapport au serveur Web ou côté client est qu'un seul projet de console API peut être utilisé pour votre application. Cela facilite l'installation pour les utilisateurs.

Service Accounts

Utile pour accéder de manière automatisée/hors connexion/planifiée à votre propre compte Google Tag Manager. (par exemple, pour créer un outil personnalisé permettant de surveiller votre propre compte Google Tag Manager et le partager avec d'autres utilisateurs).

Dépannage

Si votre access_token a expiré ou si vous utilisez le mauvais champ d'application pour un appel d'API particulier, un code d'état 401 s'affiche dans la réponse.

Si l'utilisateur autorisé n'a pas accès au compte ou au conteneur Google Tag Manager, un code d'état 403 s'affiche dans la réponse. Assurez-vous de disposer des autorisations nécessaires avec l'utilisateur approprié, et d'avoir obtenu les autorisations nécessaires pour accéder au compte ou au conteneur Tag Manager.

OAuth 2.0 Playground

OAuth 2.0 Playground vous permet de parcourir l'intégralité du flux d'autorisation via une interface Web. L'outil affiche également tous les en-têtes de requête HTTP nécessaires pour effectuer une requête autorisée. Si vous ne parvenez pas à obtenir l'autorisation de travailler dans votre propre application, vous devez essayer de la faire fonctionner via OAuth 2.0 Playground. Vous pouvez ensuite comparer les en-têtes HTTP et la requête de Playground à ce que votre application envoie. Cette vérification vous permet de vous assurer facilement que le format de vos requêtes est correct.

Autorisation non valide

Si vous recevez une réponse d'erreur invalid_grant lorsque vous tentez d'utiliser un jeton d'actualisation, l'erreur peut être causée par l'une des raisons suivantes, ou les deux:

  1. L'horloge de votre serveur n'est pas synchronisée avec NTP.
  2. Vous avez dépassé la limite de jetons d'actualisation.
    Les applications peuvent demander plusieurs jetons d'actualisation pour accéder à un seul compte Google Tag Manager. Cela peut s'avérer utile lorsqu'un utilisateur souhaite installer une application sur plusieurs machines et accéder au même compte Google Tag Manager. Dans ce cas, deux jetons d'actualisation sont requis, un pour chaque installation. Lorsque le nombre de jetons d'actualisation dépasse la limite, les jetons plus anciens ne sont plus valides. Si l'application tente d'utiliser un jeton d'actualisation non valide, une erreur invalid_grant est renvoyée. Chaque combinaison ID client/compte unique peut comporter jusqu'à 25 jetons d'actualisation. Notez que cette limite est susceptible d'être modifiée. Si l'application continue de demander des jetons d'actualisation pour la même combinaison client-ID/compte, une fois le 26e jeton émis, le premier jeton d'actualisation émis n'est plus valide. Le 27e jeton d'actualisation demandé invalide le 2e jeton émis, et ainsi de suite.