Validation du niveau d'accès limité

Certaines API Google (celles qui acceptent Sensible ou Champs d'application restreints ) impose des exigences pour les 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 portées limitées 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 afin d'accéder à ces données, vous utilisez appelées champs d'application, pour spécifier le type de données auxquelles vous souhaitez accéder et le niveau d'accès dont vous avez besoin. Si votre application demande sensitive ou champs d'application restreints, vous devez procéder à la validation à moins que son utilisation ne relève d'une exception.

Les niveaux d'accès restreints sont moins nombreux que les niveaux d'accès sensibles. La validation Questions fréquentes sur la validation de l'API OAuth : contient la liste actuelle des champs d'application sensibles et restreints. Ces champs d'application offrent un large accès aux données utilisateur Google et nécessitent une vérification de ces champs d'application avant de demander les niveaux d'accès à partir d'un compte Google. Pour en savoir plus , consultez le Règlement sur les données utilisateur dans les services des API Google et Exigences supplémentaires pour des champs d'application d'API spécifiques ou la page Google Developers spécifique au produit. Si vous stockez ou transmettez un champ d'application restreint des données sur les serveurs, vous devez effectuer une enquête de sécurité évaluation.

Comprendre les portées limitées

Si votre application demande des niveaux d'accès restreints et n'est pas éligible aux exception, vous devez respecter les Exigences supplémentaires pour les champs d'application d'API spécifiques des données utilisateur des services d'API Google Le règlement ou les exigences spécifiques au produit Page du développeur Google, ce qui nécessite un processus d'examen plus approfondi.

Comprendre l'utilisation de votre portée

• Vérifiez les niveaux d'accès que votre application utilise ou que vous souhaitez utiliser. Pour connaître votre utilisation existante du champ d'application, recherchez dans le code source de votre application tous les champs d'application envoyés avec des requêtes d'autorisation.
• Déterminer que chaque champ d'application demandé est nécessaire pour les actions prévues par la fonctionnalité de votre application et utilise le principe du moindre privilège pour fournir cette fonctionnalité. Une API Google dispose généralement documentation de référence sur les la page Google Developers pour ses points de terminaison, y compris le champ d'application requis pour appeler ou des propriétés spécifiques qu'il contient. Pour en savoir plus sur les champs d'application pour les points de terminaison de l'API appelés par votre application, consultez la documentation de référence les 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 dans le respect des règles de de l'API et de la manière que vous représentez aux utilisateurs dans les actions de votre application et dans vos règles de confidentialité.
• Reportez-vous à la documentation de l'API pour en savoir plus sur chaque champ d'application, y compris son potentiel sensitive or restricted état.
• Déclarez tous les niveaux d'accès utilisés par votre application sur la page de configuration des écrans de consentement OAuth de API Console. Les portées que vous spécifiez sont regroupées dans des catégories sensibles ou restreintes pour mettre en évidence toute validation supplémentaire requise.
• Identifiez le champ d'application le plus adapté aux données utilisées par votre intégration, reconfirmez que tout fonctionne toujours dans un environnement de test, puis préparez-vous à envoyer la validation.

Veillez à tenir compte du temps nécessaire à 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 se produit si l'application accède aux données utilisateur Google ou est en mesure d'y accéder depuis ou via un serveur. Dans le système doit être soumis à une vérification annuelle évaluation de la sécurité réalisée par un évaluateur tiers indépendant approuvé par Google. Pour cette raison, la procédure de validation des niveaux d'accès restreints peut prendre plusieurs semaines. Notez que toutes les applications doivent suivre marque de validation. Cette opération prend généralement deux à trois jours ouvrés si les informations a changé depuis la dernière validation approuvée de l'écran de consentement OAuth.

Types d'applications autorisés

Certains types d'applications peuvent accéder aux champs d'application restreints pour chaque produit. Vous trouverez d'application spécifique sur la page Page Google Developers (par exemple, le règlement de l'API Gmail)

Il est de votre responsabilité 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 sélectionner de la question Quelles fonctionnalités utiliserez-vous ? lorsque vous enverrez votre 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 soumises à des restrictions des utilisateurs Google et qui peut accéder aux données à partir d'un serveur tiers ou via celui-ci doit passer une évaluation de sécurité réalisée par des évaluateurs de sécurité Google. Cette évaluation permet de garantir la sécurité sécurité des données Vérifier que toutes les applications qui accèdent aux données utilisateur Google sont capables de gérer des données de manière sécurisée et de supprimer les données utilisateur à 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 aux niveaux d'accès restreints validés, les applications doivent être une nouvelle vérification de conformité et une évaluation de sécurité au moins tous les 12 mois après votre la date d'approbation de la lettre d'évaluation (LOA) de l'évaluateur. Si votre application ajoute un champ d'application restreint, votre l'application devra peut-être être réévaluée pour couvrir la portée supplémentaire si elle n'était pas incluse dans une l'évaluation de la sécurité.

L'équipe d'examen Google vous envoie un e-mail lorsque vous devez recertifier votre application. Pour vous assurer que les bons membres de votre équipe sont informés de cette obligation annuelle, associez des comptes Google supplémentaires à votre API Console projet en tant que propriétaire ou éditeur. Il est également utile de garder à jour les adresses e-mail d'assistance utilisateur et de contact des développeurs qui sont spécifiés dans le API Console OAuth Google Consent Screen page

Étapes à suivre pour préparer la validation

Toutes les applications qui utilisent les API Google pour demander l'accès aux données doivent suivre les étapes ci-dessous pour : effectuer la validation de la marque:

1. Vérifiez que votre application ne correspond à aucun des cas d'utilisation de la section Exceptions aux exigences de validation.
2. Assurez-vous que votre application respecte les exigences de branding des API ou du produit associés. Par exemple, consultez les consignes relatives à la marque. pour les champs d'application Google Sign-In.
3. Validez la propriété des domaines autorisés de votre projet dans la Google Search Console. Utiliser un compte Google Compte associé à votre API Console projet en tant que propriétaire ou éditeur.
4. Assurez-vous que toutes les informations de branding sur l'écran de consentement OAuth, telles que le nom de l'application, l'adresse e-mail, l'URI de la page d'accueil, l'URI des règles de confidentialité, etc., représentent avec précision l'identité de l'application.

Exigences concernant la page d'accueil de l'application

Assurez-vous que votre page d'accueil répond aux exigences suivantes:

• Votre page d'accueil doit être accessible publiquement, et pas seulement aux utilisateurs connectés à votre site. utilisateurs.
• 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 répondent aux exigences suivantes:

• Les règles de confidentialité doivent être visibles par les utilisateurs et être hébergées dans le même domaine que votre vers la page d'accueil de l'application. Il comporte également un lien sur l'écran de consentement OAuth du Google API ConsoleNotez que la page d'accueil doit inclure un description des fonctionnalités de l'application, ainsi que des liens vers les règles de confidentialité et conditions d'utilisation facultatives.
• Ces règles doivent également préciser comment votre application accède à, 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 que vous avez publiées règles de confidentialité divulgue.
• Review example cases of privacy policies that don't meet the Limited Use requirements.

Demander la validation de votre application

Un projetGoogle API Console organise toutes vos ressources API Console . 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 les API à utiliser par ces clients et configurer un Écran de consentement OAuth qui s'affiche aux 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 le projet qui demande une vérification. Pour ce faire, utilisez Google API Console

Pour envoyer une demande de validation, procédez comme suit:

1. Vérifiez que votre application respecte les Conditions d'utilisation des API Google et les Règles concernant les informations sur l'utilisateur dans les services d'API Google.
2. Tenez à jour les rôles de propriétaire et d'éditeur des comptes associés à votre projet, ainsi que votre l'adresse e-mail d'assistance utilisateur et les coordonnées du développeur sur l'écran de consentement OAuth, dans votre API ConsoleAinsi, les bons membres de votre réseau est informée de toute nouvelle exigence.
3. Accédez à la section API ConsoleOAuth Consent Screen page.
4. Cliquez sur le bouton Sélecteur de projet.

5. Dans la boîte de dialogue Sélectionner qui s'affiche, sélectionnez votre projet. Si vous ne trouvez pas votre mais que vous connaissez l'ID de votre projet, vous pouvez créer une URL dans votre navigateur dans format:

   https://console.developers.google.com/apis/credentials/consent?project=[PROJECT_ID]

   Remplacez [PROJECT_ID] par l'ID du projet que vous souhaitez utiliser.

6. Sélectionnez le bouton Edit App (Modifier l'application).
7. Saisissez les informations nécessaires sur la page de l'écran d'autorisation OAuth, puis sélectionnez le bouton Enregistrer et continuer.
8. Utilisez le bouton Ajouter ou supprimer des niveaux d'accès pour déclarer tous les champs d'application demandés par votre application. Une l'ensemble initial de niveaux d'accès requis pour Google Sign-In sont préremplis dans le Section Champs d'application non sensibles. Les niveaux d'accès ajoutés sont classés comme non sensibles, sensitive, or restricted
9. Fournissez jusqu'à trois liens vers toute documentation pertinente sur les fonctionnalités associées de votre application.

10. Fournissez toutes les informations supplémentaires demandées concernant votre application lors des étapes suivantes.

    1. 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.
    2. Ensure your app is one of the allowed types specified in the Limited Use section of the Additional requirements for specific API scopes page.
    3. 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.

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

       1. 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.
       2. Show that the OAuth consent screen correctly displays the App Name.
       3. Show that the browser address bar of the OAuth consent screen correctly includes your app's OAuth client ID.
       4. To show how the data will be used, demonstrate the functionality that's enabled by each sensitive and restricted scope that you request.
       5. If you use multiple clients, and therefore have multiple OAuth client IDs, show how the data is accessed on each OAuth client.
    5. Select your permitted application type from the "What features will you use?" list.
    6. Describe how you will use the restricted scopes in your app and why more limited scopes aren't sufficient.
11. Si la configuration d'application que vous fournissez doit être validée, vous avez la possibilité d'envoyer l'application pour la 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 le Coordonnées du développeur et adresse e-mail d'assistance associée à votre autorisation OAuth des 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 exigences de validation

Si votre application est destinée à être utilisée dans l'un des scénarios décrits dans les sections suivantes, vous devez vous n'avez pas besoin de le 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, qui vous sont tous personnellement connus. Vous et votre nombre limité d'utilisateurs pourriez être à l'aise en progressant dans les application non validée et accordez à vos comptes personnels l'accès à votre application.

Remarque : limite d'utilisateurs limite le nombre de comptes Google pouvant accorder l'accès à votre application non validée.

Projets utilisés pour le développement, les tests ou la préproduction niveaux

Afin de respecter les règles Google OAuth 2.0, nous vous recommandons d'avoir différents projets pour des environnements de test et de production. Nous vous recommandons de ne demander la validation de votre application si vous souhaitez mettre votre application à la disposition de tout utilisateur disposant d'un compte Google. Par conséquent, si votre application 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 quitter le État de la publication au paramètre par défaut Tests : Ce paramètre signifie que votre application est en cours de développement et n'est disponibles pour les 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.

Remarque:Un écran d'avertissement pour les testeurs s'affiche toujours dans votre application, comme indiqué dans chiffre 1, une limite d'utilisateurs est appliquée et le jeton d'actualisation sa durée de vie est limitée.

Figure 1 : Écran d'avertissement pour les testeurs

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 comprendre ce que sont les comptes de service, consultez Comptes de service dans dans la documentation Google Cloud. Pour savoir comment utiliser un compte de service, consultez Utiliser OAuth 2.0 de serveur à serveur applications.

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 d'autorisation OAuth doit être configuré Utilisateur interne type. Dans ce cas, votre application peut nécessiter l'approbation d'un administrateur de l'organisation. Pour Pour en savoir plus, consultez Autres à prendre en compte pour Google Workspace.

• En savoir plus sur publics et les applications internes.
• Découvrez comment marquer votre application comme interne dans les questions fréquentes. Comment puis-je marquer mon application interne uniquement ?

Installation au niveau du domaine

Si vous prévoyez que votre application ne cible que les utilisateurs d'un compte Google Workspace ou Cloud Identity d'organisation et utilisez toujours l'ensemble du domaine l'installation, elle ne nécessite pas de validation. Cela est dû au fait qu'une règle au niveau du domaine permet à l'administrateur du domaine d'accorder l'accès aux applications tierces et internes de vos utilisateurs données. Les administrateurs de l'organisation sont les seuls comptes autorisés à ajouter l'application à un d'autorisation pour une utilisation dans leurs domaines.

Consultez les questions fréquentes pour découvrir comment configurer votre application pour une installation sur l'ensemble du domaine. Mon application compte des utilisateurs les comptes d'entreprise d'un autre domaine Google Workspace.