Certaines API Google (celles qui acceptent les champs d'application Sensible ou Restreint ) imposent des exigences aux applications qui demandent l'autorisation d'accéder aux données des consommateurs. Ces exigences supplémentaires pour les champs d'application limités exigent qu'une application démontre qu'elle est un type d'application autorisé et qu'elle soit soumise à des examens supplémentaires, y compris une évaluation de sécurité possible.
L'applicabilité des champs d'application limités dans une API dépend principalement du niveau d'accès requis pour fournir une fonctionnalité pertinente dans votre application: lecture seule, écriture seule, lecture et écriture, etc.
Lorsque vous utilisez OAuth 2.0 pour obtenir l'autorisation d'un compte Google d'accéder à ces données, vous utilisez des chaînes appelées champs d'application pour spécifier le type de données auquel vous souhaitez accéder et le niveau d'accès dont vous avez besoin. Si votre application demande des champs d'application sensibles ou restreints, vous devez suivre la procédure de validation, sauf si l'utilisation de votre application peut faire l'objet d' une exception.
Les champs d'application limités sont moins nombreux que les champs d'application sensibles. Les questions fréquentes sur la validation de l'API OAuth contiennent la liste actuelle des champs d'application sensibles et restreints. Ces champs d'application offrent un accès étendu aux données utilisateur Google et vous devez passer par un processus de validation de champ d'application avant de les demander à partir de n'importe quel compte Google. Pour en savoir plus sur cette exigence, consultez les Règles sur les données utilisateur dans les services des API Google et les Exigences supplémentaires pour les champs d'application d'API spécifiques, ou la page Google Developer spécifique au produit. Si vous stockez ou transmettez des données à champ d'application restreint sur des serveurs, vous devez effectuer une évaluation de la sécurité.
Comprendre les portées limitées
Si votre application demande des champs d'application restreints et qu'elle ne peut pas bénéficier d'une exception, vous devez respecter les exigences supplémentaires pour les champs d'application d'API spécifiques du règlement sur les données utilisateur pour les services des API Google, ou les exigences spécifiques au produit sur la page Google Developer du produit, ce qui nécessite un examen plus approfondi.
Comprendre l'utilisation de votre portée
- Examinez les champs d'application que votre application utilise ou que vous souhaitez utiliser. Pour connaître l'utilisation existante de votre champ d'application, examinez le code source de votre application pour identifier les champs d'application envoyés avec les requêtes d'autorisation.
- Vérifiez que chaque champ d'application demandé est nécessaire pour les actions prévues de la fonctionnalité de votre application et qu'il utilise le niveau de privilège le moins élevé nécessaire pour fournir la fonctionnalité. Une API Google dispose généralement d'une documentation de référence sur la page Google Developer du produit pour ses points de terminaison, qui inclut le champ d'application requis pour appeler le point de terminaison ou des propriétés spécifiques. Pour en savoir plus sur les portées d'accès requises pour les points de terminaison d'API que votre application appelle, consultez la documentation de référence de ces points de terminaison. For example, for an app that only uses Gmail APIs to occasionally send emails on a user's behalf, don't request the scope that provides full access to the user's email data.
- Les données que vous recevez d'une API Google ne doivent être utilisées que conformément aux règles de l'API et de la manière que vous présentez à vos utilisateurs dans les actions de votre application et dans vos règles de confidentialité.
- Consultez la documentation de l'API pour en savoir plus sur chaque champ d'application, y compris son état sensitive or restricted potentiel.
- Déclarez tous les champs d'application utilisés par votre application dans le de . Les champs d'application que vous spécifiez sont regroupés dans des catégories sensibles ou restreintes pour mettre en évidence toute validation supplémentaire requise.
- Trouvez la meilleure portée correspondant aux données utilisées par votre intégration, comprenez son utilisation, vérifiez à nouveau que tout fonctionne toujours dans un environnement de test, puis préparez-vous à l'envoyer pour vérification.
Veillez à prendre en compte le temps nécessaire pour effectuer la validation dans votre plan de lancement pour votre application ou toute nouvelle fonctionnalité nécessitant un nouveau champ d'application. L'une de ces exigences supplémentaires s'applique si l'application accède aux données utilisateur Google ou a la possibilité d'y accéder à partir d'un serveur ou via un serveur. Dans ce cas, le système doit faire l'objet d'une évaluation de la sécurité annuelle par un évaluateur tiers indépendant approuvé par Google. C'est pourquoi le processus de validation des champs d'application restreints peut prendre plusieurs semaines. Notez que toutes les applications doivent d'abord effectuer la validation de la marque, qui prend généralement deux à trois jours ouvrés, si les informations sur la marque ont changé depuis la dernière validation de l'écran d'autorisation OAuth approuvée.
Types d'applications autorisés
Certains types d'applications peuvent accéder à des champs d'application limités pour chaque produit. Vous trouverez les types d'applications sur la page Google Developers spécifique au produit (par exemple, le règlement de l'API Gmail).
Il vous incombe de comprendre et de déterminer le type de votre application. Toutefois, si vous n'êtes pas sûr du type d'application de votre application, vous pouvez ne sélectionner aucune option pour la question Quelles fonctionnalités allez-vous utiliser ? lorsque vous envoyez l'application pour validation. L'équipe de validation de l'API Google déterminera ensuite le type d'application.
Évaluation de la sécurité
Chaque application qui demande l'accès aux données limitées des utilisateurs Google et qui peut accéder aux données à partir d'un serveur tiers ou via celui-ci doit faire l'objet d'une évaluation de sécurité réalisée par des évaluateurs de sécurité Google. Cette évaluation permet de protéger les données des utilisateurs Google en vérifiant que toutes les applications qui accèdent aux données utilisateur Google sont capables de gérer les données de manière sécurisée et de les supprimer à la demande de l'utilisateur.
Pour standardiser notre évaluation de la sécurité, nous utilisons l' App Defense Alliance et le framework d'évaluation de la sécurité des applications cloud (CASA).
Comme indiqué précédemment, pour conserver l'accès à tout champ d'application vérifié et limité, les applications doivent être réexaminées pour vérifier leur conformité et effectuer une évaluation de la sécurité au moins tous les 12 mois après la date d'approbation de la lettre d'évaluation de votre évaluateur. Si votre application ajoute un nouveau champ d'application restreint, elle devra peut-être être réévaluée pour couvrir le champ d'application supplémentaire s'il n'était pas inclus dans une évaluation de sécurité précédente.
L'équipe d'examen Google vous envoie un e-mail lorsqu'il est temps de recertifier votre application. Pour vous assurer que les bons membres de votre équipe sont informés de cette application annuelle, associez des comptes Google supplémentaires à votre projet en tant que propriétaire ou éditeur. Il permet également de mettre à jour les adresses e-mail d'assistance utilisateur et de contact du développeur spécifiées dans le OAuth Google.
Étapes à suivre pour préparer la validation
Toutes les applications qui utilisent les API Google pour demander l'accès à des données doivent suivre la procédure ci-dessous pour valider leur marque:
- Vérifiez que votre application ne correspond à aucun des cas d'utilisation de la section Exceptions aux exigences de validation.
- Assurez-vous que votre application respecte les exigences de branding des API ou du produit associés. Par exemple, consultez les consignes relatives au branding pour les portées Google Sign-In.
- Validez la propriété des domaines autorisés de votre projet dans la Google Search Console. Utilisez un compte Google associé à votre projet API Console en tant que propriétaire ou éditeur.
- Assurez-vous que toutes les informations de branding sur l'écran d'autorisation OAuth, telles que le nom de l'application, l'adresse e-mail d'assistance, l'URI de la page d'accueil, l'URI des règles de confidentialité, etc., représentent précisément l'identité de l'application.
Exigences concernant la page d'accueil de l'application
Assurez-vous que votre page d'accueil respecte les conditions suivantes:
- Votre page d'accueil doit être accessible à tous les internautes, et pas seulement aux utilisateurs connectés à votre site.
- La pertinence de votre page d'accueil par rapport à l'application en cours d'examen doit être claire.
- Les liens vers la fiche de votre application sur le Google Play Store ou sa page Facebook ne sont pas considérés comme des pages d'accueil d'application valides.
Exigences concernant le lien vers les règles de confidentialité de l'application
Assurez-vous que les règles de confidentialité de votre application respectent les exigences suivantes:
- Les règles de confidentialité doivent être visibles par les utilisateurs, hébergées sur le même domaine que la page d'accueil de votre application et associées à l'écran d'autorisation OAuth de l' Google API Console. Notez que la page d'accueil doit inclure une description des fonctionnalités de l'application, ainsi que des liens vers les règles de confidentialité et les conditions d'utilisation facultatives.
- Les règles de confidentialité doivent indiquer la manière dont votre application accède, utilise, stocke ou partage les données utilisateur Google. The privacy policy must comply with the Google API Services User Data Policy and the Limited Use requirements for restricted scopes. Vous devez limiter votre utilisation des données utilisateur Google aux pratiques décrites dans vos règles de confidentialité publiées.
- Review example cases of privacy policies that don't meet the Limited Use requirements.
Envoyer votre application pour validation
Un projet organise toutes vos ressources . Un projet comprend un ensemble de comptes Google associés autorisés à effectuer des opérations de projet, un ensemble d'API activées, ainsi que des paramètres de facturation, d'authentification et de surveillance pour ces API. Par exemple, un projet peut contenir un ou plusieurs clients OAuth, configurer des API à utiliser par ces clients et configurer un écran de consentement OAuth qui s'affiche auprès des utilisateurs avant qu'ils n'autorisent l'accès à votre application.
Si l'un de vos clients OAuth n'est pas prêt pour la production, nous vous suggérons de le supprimer du projet qui demande la validation. Vous pouvez le faire dans .
Pour demander la validation de votre compte, procédez comme suit:
- Assurez-vous que votre application respecte les Conditions d'utilisation des API Google et le Règlement sur les données utilisateur dans les services d'API Google.
- Mettez à jour les rôles de propriétaire et d'éditeur des comptes associés à votre projet, ainsi que l'adresse e-mail d'assistance utilisateur et les coordonnées du développeur de l'écran d'autorisation OAuth, dans votre . Vous vous assurez ainsi que les bons membres de votre équipe sont informés de toute nouvelle exigence.
- Accédez à la section OAuth .
- Cliquez sur le bouton Sélecteur de projet.
-
Dans la boîte de dialogue Sélectionner qui s'affiche, sélectionnez votre projet. Si vous ne trouvez pas votre projet, mais que vous connaissez son ID, vous pouvez créer une URL dans votre navigateur au format suivant:
?project=[PROJECT_ID]
Remplacez [PROJECT_ID] par l'ID du projet que vous souhaitez utiliser.
- Sélectionnez le bouton Modifier l'application.
- Saisissez les informations nécessaires sur la page de l'écran d'autorisation OAuth, puis sélectionnez le bouton Enregistrer et continuer.
- Utilisez le bouton Ajouter ou supprimer des champs d'application pour déclarer tous les champs d'application demandés par votre application. Un ensemble initial de champs d'application nécessaires pour Google Sign-In est prérempli dans la section Champs d'application non sensibles. Les niveaux d'accès ajoutés sont classés comme non sensibles, sensitive, or restricted.
- Fournissez un maximum de trois liens vers toute documentation pertinente pour les fonctionnalités associées de votre application.
-
Fournissez toutes les informations supplémentaires demandées concernant votre application lors des étapes suivantes.
- Ensure your app complies with the Additional requirements for specific API scopes, which includes undergoing an annual security assessment if your app accesses restricted scope Google users' data from or through a third-party server.
- Ensure your app is one of the allowed types specified in the Limited Use section of the Additional requirements for specific API scopes page.
- If your app is a task automation platform, your demonstration video must showcase how multiple API workflows are created and automated, and in which directions user data flows.
-
Prepare a video that fully demonstrates how a user initiates and grants access to the requested scopes and shows, in detail, the usage of the granted sensitive and restricted scopes in the app. Upload the video to YouTube Studio and set Visibility as Unlisted. You need to provide a link to the demonstration video in the YouTube link field.
- Show the OAuth grant process that users will experience, in English. This includes the consent flow and, if you use Google Sign-In, the sign-in flow.
- Show that the OAuth consent screen correctly displays the App Name.
- Show that the browser address bar of the OAuth consent screen correctly includes your app's OAuth client ID.
- To show how the data will be used, demonstrate the functionality that's enabled by each sensitive and restricted scope that you request.
- If you use multiple clients, and therefore have multiple OAuth client IDs, show how the data is accessed on each OAuth client.
- Select your permitted application type from the "What features will you use?" list.
- Describe how you will use the restricted scopes in your app and why more limited scopes aren't sufficient.
- Si la configuration de l'application que vous fournissez doit être validée, vous pouvez la soumettre à validation. Remplissez les champs obligatoires, puis cliquez sur Envoyer pour lancer le processus de validation.
Une fois que vous avez envoyé votre application, l'équipe Trust & Safety de Google vous contacte par e-mail pour vous fournir les informations supplémentaires dont elle a besoin ou les étapes que vous devez suivre. Vérifiez vos adresses e-mail dans la section Coordonnées du développeur et l'adresse e-mail d'assistance de votre écran d'autorisation OAuth pour les demandes d'informations supplémentaires. Vous pouvez également consulter la page de l'écran d'autorisation OAuth de votre projet pour confirmer son état d'examen actuel, y compris si le processus d'examen est mis en veille en attendant votre réponse.
Exceptions aux conditions de validation
Si votre application sera utilisée dans l'un des scénarios décrits dans les sections suivantes, vous n'avez pas besoin de la soumettre pour examen.
Usage personnel
Par exemple, si vous êtes le seul utilisateur de votre application ou si elle n'est utilisée que par quelques utilisateurs que vous connaissez personnellement. Vous et votre nombre limité d'utilisateurs pouvez passer à l'écran de l'application non validée et accorder à vos comptes personnels l'accès à votre application.
Projets utilisés dans le développement, les tests ou l'environnement de préproduction tiers
Pour respecter les règles Google OAuth 2.0, nous vous recommandons de disposer de projets distincts pour les environnements de test et de production. Nous vous recommandons de ne soumettre votre application à validation que si vous souhaitez la rendre disponible pour tous les utilisateurs disposant d'un compte Google. Par conséquent, si votre application est en phase de développement, de test ou de préproduction, la validation n'est pas requise.
Si votre application est en phase de développement ou de test, vous pouvez laisser l'état de publication Publishing Status (État de publication) sur la valeur par défaut Testing (Test). Ce paramètre signifie que votre application est toujours en cours de développement et n'est accessible qu'aux utilisateurs que vous ajoutez à la liste des utilisateurs tests. Vous devez gérer la liste des comptes Google impliqués dans le développement ou les tests de votre application.
Données appartenant au service uniquement
Si votre application utilise un compte de service pour n'accéder qu'à ses propres données et qu'elle n'accède à aucune donnée utilisateur (associée à un compte Google), vous n'avez pas besoin de demander la validation.
Pour en savoir plus sur les comptes de service, consultez la section Comptes de service dans la documentation Google Cloud. Pour savoir comment utiliser un compte de service, consultez la page Utiliser OAuth 2.0 pour les applications de serveur à serveur.
Ils sont réservés à un usage interne
Cela signifie que l'application n'est utilisée que par les membres de votre organisation Google Workspace ou Cloud Identity. Le projet doit appartenir à l'organisation, et son écran de consentement OAuth doit être configuré pour un type d'utilisateur interne. Dans ce cas, votre application peut nécessiter l'approbation d'un administrateur de l'organisation. Pour en savoir plus, consultez la section Remarques supplémentaires pour Google Workspace.
- En savoir plus sur les applications publiques et internes
- Découvrez comment marquer votre application comme interne dans la FAQ Comment puis-je marquer mon application comme étant réservée à un usage interne.
Installation au niveau du domaine
Si vous prévoyez que votre application ne ciblera que les utilisateurs d'une organisation Google Workspace ou Cloud Identity et que vous utiliserez toujours une installation à l'échelle du domaine, elle ne nécessitera pas de validation. En effet, une installation au niveau du domaine permet à un administrateur de domaine d'autoriser les applications tierces et internes à accéder aux données de vos utilisateurs. Seuls les administrateurs de l'organisation peuvent ajouter l'application à une liste d'autorisation pour l'utiliser dans leurs domaines.
Découvrez comment installer votre application au niveau du domaine dans les questions fréquentes Mon application compte des utilisateurs disposant de comptes professionnels d'un autre domaine Google Workspace.