Pour configurer OAuth pour votre application, vous devez configurer un workflow OAuth et activer les champs d'application OAuth de l'API Data Portability.
Configurer un workflow OAuth
Pour configurer un flux OAuth pour votre application, suivez les étapes de base décrites dans la documentation Google Identity.
La plupart des développeurs utilisent le flux Applications Web côté serveur pour obtenir le consentement OAuth, mais vous pouvez également utiliser le flux d'application Web JavaScript ou le flux d'application mobile et de bureau.
Les exportations peuvent prendre plus de temps que la durée de vie d'un jeton d'accès, ou l'utilisateur peut accorder un accès de 30 ou 180 jours. Vous devrez peut-être obtenir un jeton d'actualisation et l'échanger régulièrement contre un nouveau jeton d'accès. Pour en savoir plus, consultez les articles Actualiser un jeton d'accès pour les applications Web et Actualiser un jeton d'accès pour les applications mobiles et de bureau.
Important: Le renouvellement du jeton OAuth n'est disponible que pour les utilisateurs si l'état de publication de votre client OAuth est En production, et non Test. De plus, les jetons accordés aux clients OAuth avec un état de publication Test expirent toujours au bout de sept jours, même si vous sélectionnez une durée de 30 ou 180 jours. Pour en savoir plus, consultez Configurer votre écran de consentement OAuth.
Champs d'application OAuth de l'API Data Portability
Lorsque vous configurez votre application API Data Portability pour OAuth, activez les champs d'application OAuth de l'API Data Portability qui sont pertinents pour votre application. Certains champs d'application sont sensitive et restricted, et sont soumis à des exigences supplémentaires.
Lorsque vous ajoutez les habilitations de l'API Data Portability à votre flux OAuth, il est possible que votre utilisateur donne son consentement à certaines habilitations, mais pas à toutes. Votre application doit pouvoir gérer ces cas en:
- Autoriser les exportations de données partielles
- Informer l'utilisateur qu'il n'a pas sélectionné tous les champs d'application nécessaires (et échouer de manière élégante)
- Demander à l'utilisateur les autres consentements
De plus, un utilisateur peut choisir de vous accorder un accès à ses données une seule fois, ou pendant 30 ou 180 jours.
- Si un utilisateur vous accorde un accès ponctuel, votre application est autorisée à effectuer une seule exportation de données pour ce consentement spécifique. Pour télécharger à nouveau les données, vous devez obtenir un nouveau consentement de l'utilisateur.
- Si un utilisateur vous accorde un accès basé sur le temps, votre application est autorisée à effectuer des exportations de données pendant la durée spécifiée ou jusqu'à ce que l'utilisateur révoque son consentement.
- Vous pouvez également choisir d'appliquer des filtres temporels à votre requête pour exporter des données pour une période spécifique, comme les six derniers mois.
Notez également que pendant le flux OAuth, votre application ne sait pas quel compte Google a été utilisé pour donner son autorisation. Le jeton OAuth que votre application reçoit est opaque.
Pour en savoir plus sur la façon dont les utilisateurs partagent des données, consultez Partager une copie de vos données avec un tiers.
Restrictions concernant les champs d'application
Cette section traite des restrictions dans les champs d'application qui entraînent des erreurs.
Champs d'application mixtes
Les requêtes pour les champs d'application de l'API Portabilité des données (par exemple, https://www.googleapis.com/auth/dataportability.*) ne peuvent pas être mélangées à d'autres champs d'application (par exemple, https://www.googleapis.com/auth/userinfo.email). Voici un exemple de requête incorrecte, avec la partie limitée en gras:
https://accounts.google.com/o/oauth2/v2/auth?
client_id=client_id&
redirect_uri=redirect_uri&
response_type=token&
scope=https://www.googleapis.com/auth/dataportability.myactivity.search+https://www.googleapis.com/auth/userinfo.email&
include_granted_scopes=false
Étendues précédemment accordées
Vous ne devez jamais définir include_granted_scopes=true lorsque vous demandez des champs d'application DPAPI.
Voici un exemple de requête incorrecte, avec la partie restreinte en gras:
https://accounts.google.com/o/oauth2/v2/auth?
client_id=client_id&
redirect_uri=redirect_uri&
response_type=token&
scope=https://www.googleapis.com/auth/dataportability.myactivity.search&
include_granted_scopes=true
Trop de champs d'application
Si trop d'étendues sont ajoutées à votre requête, vous pouvez rencontrer une erreur 400 bad request. Cela se produit lorsque la longueur de l'URL dépasse la limite prise en charge par les navigateurs. Pour résoudre ce problème, divisez vos requêtes d'étendues en plusieurs lots plus petits et utilisez l'autorisation incrémentielle pour demander le consentement pour chaque lot.
Catégories de champs d'application
Pour obtenir la liste de tous les champs d'application OAuth compatibles avec l'API Data Portability et leurs catégories, consultez la section Champs d'application OAuth disponibles. Pour obtenir la liste de tous les groupes de ressources et des portées OAuth compatibles avec un service particulier, consultez la page de référence du schéma de ce service.