Autorisation

Ce guide explique comment une application autorise les requêtes à l'API User Deletion.

Autoriser les requêtes

Avant de pouvoir consulter les informations de leur compte sur le site Web de Google Analytics, les utilisateurs doivent d'abord se connecter à leur compte Google. De même, lorsque les utilisateurs accèdent à votre application pour la première fois, ils doivent l'autoriser à accéder à leurs données.

Chaque requête envoyée par votre application à l'API Analytics 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 Analytics 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 Analytics 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 des étapes supplémentaires, comme l'utilisation de jetons d'actualisation en vue de l'acquisition 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 concernant le niveau d'accès OAuth 2.0 pour l'API Analytics:

Portée Signification
https://www.googleapis.com/auth/analytics.user.deletion Supprimez des données à l'aide de l'API User Deletion.

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).

Conseil : Les bibliothèques clientes des API Google peuvent gérer une partie de la procédure d'autorisation à votre place. Elles sont proposées pour une grande variété de langages de programmation. Pour en savoir plus, explorez les bibliothèques clientes et les exemples de code présentés sur la page Installer les bibliothèques clientes.

Flux OAuth 2.0 courants

Voici la liste des cas d'utilisation courants pour des flux OAuth 2.0 spécifiques:

Serveur Web

Ce flux est adapté à l'accès automatisé, hors connexion ou planifié aux données Google Analytics d'un utilisateur.

Exemple :

  • Mise à jour automatique des tableaux de bord des utilisateurs avec les dernières données Google Analytics.

Côté client

Ce flux est idéal pour les applications lorsque les utilisateurs interagissent directement avec l'application pour accéder à leurs données Google Analytics dans un navigateur. Il élimine le besoin de fonctionnalités côté serveur, mais rend les rapports automatisés, hors connexion ou planifiés peu pratiques.

Exemple :

Applications installées

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

Exemples :

  • Un widget pour ordinateur de bureau sur un PC ou un Mac
  • Un plug-in pour un système de gestion de contenu : l'avantage de ce flux par rapport au serveur Web ou au côté client est qu'un seul projet de console d'API peut être utilisé pour votre application. Cela permet de créer des rapports consolidés et une installation plus simple pour les utilisateurs.

Service Accounts

Les comptes de service permettent d'accéder de manière automatisée, hors connexion ou planifiée aux données Google Analytics de votre propre compte. Par exemple, pour créer un tableau de bord en direct de vos propres données Google Analytics et le partager avec d'autres utilisateurs.

Pour commencer à utiliser l'API Analytics, vous devez d'abord utiliser l'outil de configuration, qui vous guide tout au long de la création d'un projet dans la console Google APIs, de l'activation de l'API et de la création d'identifiants.

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

  1. Cliquez sur Créer des identifiants > Clé de compte de service.
  2. Indiquez si vous souhaitez 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 d'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 la stocker en toute sécurité.

Dépannage

Votre autorisation échoue dans les cas suivants:

  • Vous recevrez un code d'état 401 si votre access_token a expiré ou si vous utilisez le mauvais champ d'application pour l'API.

  • Vous recevrez un code d'état 403 si l'utilisateur autorisé n'a pas accès à la vue (profil). Assurez-vous d'être autorisé avec l'utilisateur approprié et qu'il dispose bien de la vue (profil) que vous avez sélectionnée.

OAuth 2.0 Playground

Cet outil vous permet de suivre l'intégralité du flux d'autorisation via une interface Web. L'outil affiche également tous les en-têtes de requête HTTP requis pour effectuer une requête autorisée. Si vous ne parvenez pas à obtenir l'autorisation 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 l'espace de jeu à ce que votre application envoie à Google Analytics. Cette vérification est un moyen simple de vous assurer que vous mettez en forme correctement vos requêtes.

Accès non valide

Lorsque vous essayez d'utiliser un jeton d'actualisation, l'opération suivante renvoie une erreur invalid_grant:

Les applications peuvent demander plusieurs jetons d'actualisation pour accéder à un seul compte Google Analytics.

Par exemple, si un utilisateur souhaite installer une application sur plusieurs machines et accéder au même compte Google Analytics, un jeton distinct est requis pour chaque machine. Lorsque le nombre de jetons d'actualisation dépasse la limite, les jetons plus anciens deviennent non valides. Si l'application tente d'utiliser un jeton de rafraîchissement invalidé, une réponse d'erreur invalid_grant est renvoyée.

La limite pour chaque paire unique de client OAuth 2.0 et de compte Google Analytics est de 25 jetons d'actualisation. Si l'application continue de demander des jetons d'actualisation pour la même paire client/compte, une fois le 26e jeton émis, le 1er jeton d'actualisation précédemment émis deviendra non valide. Le 27e jeton de rafraîchissement demandé invaliderait le 2e jeton précédemment émis, et ainsi de suite.