Validation du niveau d'accès limité

Certaines API Google (celles qui acceptent les niveaux d'accès sensibles ou restreints ) ont des exigences concernant les applications qui demandent l'autorisation d'accéder aux données des consommateurs. Ces exigences supplémentaires concernant les niveaux d'accès restreints exigent que l'application prouve qu'il s'agit d'un type d'application autorisé et doit être soumise à un examen supplémentaire, y compris une évaluation de sécurité possible.

L'applicabilité des niveaux d'accès restreints 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 requiert des niveaux d'accès sensibles ou limités, vous devez terminer la procédure de validation, sauf si l'utilisation de votre application peut faire l'objet d'une exception.

Les niveaux d'accès restreints sont moins nombreux que les niveaux d'accès sensibles. Les questions fréquentes sur la validation de l'API OAuth dans Verification contiennent la liste actuelle des niveaux d'accès sensibles et restreints. Ces champs d'application offrent un accès étendu aux données utilisateur Google et exigent que vous vous soumettiez à une procédure de vérification des champs d'application avant de demander les champs d'application à partir d'un compte Google. Pour en savoir plus sur cette exigence, consultez le Règlement sur les données utilisateur dans les services d'API Google et les Exigences supplémentaires pour les champs d'application d'API spécifiques ou la page des développeurs Google spécifiques 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 niveaux d'accès restreints

Si votre application demande des niveaux d'accès restreints et qu'elle ne peut pas faire l'objet d'une exception, vous devez respecter les exigences supplémentaires pour des champs d'application d'API spécifiques du règlement sur les données utilisateur dans les services d'API Google, ou les exigences spécifiques aux produits sur la page Google Developers du produit, qui nécessite un processus d'examen plus approfondi.

Comprendre l'utilisation du champ d'application

  • Vérifiez les niveaux d'accès que votre application utilise ou que vous souhaitez utiliser. Pour connaître votre utilisation actuelle des champs d'application, examinez le code source de votre application pour rechercher tous les champs d'application envoyés avec les requêtes d'autorisation.
  • Déterminez que chaque champ d'application demandé est nécessaire aux actions prévues de votre fonctionnalité d'application et utilise le moindre privilège pour fournir la fonctionnalité. Une API Google dispose généralement de documentation de référence sur la page Google Developers du produit concernant ses points de terminaison, qui inclut le champ d'application requis pour appeler le point de terminaison ou les propriétés spécifiques qu'il contient. Pour en savoir plus sur les niveaux d'accès nécessaires pour les points de terminaison d'API appelés par votre application, consultez la documentation de référence sur 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 dans le respect des règles 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 état sensitive or restricted potentiel.
  • Déclarez tous les champs d'application utilisés par votre application sur la page des champs d'application de configuration de l'écran de consentement OAuth de API Console. Les niveaux d'accès que vous spécifiez sont regroupés par catégories sensibles ou limitées afin de mettre en évidence toute vérification supplémentaire requise.
  • Identifiez le champ d'application qui correspond le mieux aux données utilisées par votre intégration, comprenez leur utilisation, revérifiez que tout fonctionne toujours dans un environnement de test, puis préparez-vous à envoyer votre demande pour validation.

Veillez à tenir compte du temps nécessaire à la validation de votre plan de lancement pour votre application ou de 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 a la possibilité d'y accéder depuis ou via un serveur. Dans ce cas, le système doit se soumettre à une évaluation de sécurité annuelle par un évaluateur tiers indépendant et approuvé par Google. Pour cette raison, le processus de validation des niveaux d'accès restreints peut prendre plusieurs semaines. Notez que toutes les applications doivent d'abord suivre l'étape de validation de la marque, qui prend généralement deux à trois jours ouvrés si les informations de branding ont changé depuis la dernière validation de l'écran de consentement OAuth.

Types d'applications autorisés

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

Vous êtes tenu 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 utiliserez-vous lorsque vous envoyez 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 à accéder aux données restreintes des utilisateurs Google, et qui a la possibilité d'y accéder depuis ou via un serveur tiers, doit être soumise à une évaluation de sécurité réalisée par des évaluateurs de sécurité Google. Cette évaluation contribue à protéger les données des utilisateurs Google en vérifiant que toutes les applications qui accèdent aux données utilisateur Google démontrent leur capacité à les traiter de manière sécurisée et à les supprimer à la demande d'un utilisateur.

Pour standardiser notre évaluation de la sécurité, nous utilisons l' App Defense Alliance et le framework CASA (Cloud Application Security Assessment Framework).

Comme indiqué précédemment, pour conserver l'accès aux champs d'application restreints validés, la conformité des applications doit être revalidée et une évaluation de sécurité doit être effectuée au moins tous les 12 mois après la date d'approbation du mandat d'évaluation de votre évaluateur. Si votre application ajoute un nouveau champ d'application restreint, elle devra peut-être être réévaluée afin de couvrir le champ d'application supplémentaire si elle n'a pas été incluse dans une évaluation de sécurité précédente.

L'équipe d'examinateurs Google vous envoie un e-mail lorsqu'il est temps de certifier à nouveau votre application. Pour vous assurer que les bons membres de votre équipe sont informés de cette mesure d'application annuelle, associez d'autres comptes Google à votre API Console projet en tant que propriétaire ou éditeur. Il est également utile de tenir à jour les adresses e-mail de contact pour les développeurs et l'assistance utilisateur spécifiées dans le Consent Screen pageGoogle API Console OAuth.

Étapes de préparation à 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 valider 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 des produits 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. Utilisez un compte Google associé à votre projet API Console en tant que propriétaire ou éditeur.
  4. Assurez-vous que toutes les informations de branding affichées sur l'écran de consentement 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 fidèlement 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 au public, et pas seulement aux utilisateurs connectés à votre site.
  • La pertinence de votre page d'accueil par rapport à l'application qui est 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 valides.

Exigences concernant les liens 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 être accessibles via un lien sur l'écran de consentement OAuth du 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 des conditions d'utilisation facultatives.
  • Ces règles doivent indiquer la manière dont votre application accède aux données utilisateur de Google, les utilise, les stocke ou les partage. The privacy policy must comply with the Google API Services User Data Policy and the Limited Use requirements for restricted scopes. Vous devez limiter l'utilisation des données utilisateur Google aux pratiques mentionnées dans vos règles de confidentialité.
  • Review example cases of privacy policies that don't meet the Limited Use requirements.

Faire valider votre application

Un projetGoogle API Console organise toutes vos API Console ressources. Un projet se compose d'un ensemble de comptes Google associés autorisés à effectuer des opérations sur des projets, d'un ensemble d'API activées, et de 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 destinées à ces clients et configurer un écran de consentement OAuth qui s'affiche avant qu'ils n'autorisent l'accès à votre application.

Si certains de vos clients OAuth ne sont pas prêts pour la production, nous vous suggérons de les supprimer du projet qui demande une validation. Vous pouvez le faire dans Google API Console.

Pour demander la validation de votre compte, procédez comme suit:

  1. Assurez-vous que votre application respecte les Conditions d'utilisation des API Google et le Règlement sur les données utilisateur des services d'API Google.
  2. Dans votre API Console, conservez à jour les rôles de propriétaire et d'éditeur des comptes associés à votre projet, ainsi que l'adresse e-mail de l'assistance utilisateur et les coordonnées du développeur sur votre écran de consentement OAuth. Cela permet de s'assurer que les membres appropriés de votre équipe sont informés de toute nouvelle exigence.
  3. Accédez à API Console OAuth Consent Screen page.
  4. Cliquez sur le bouton Sélecteur de projet.
  5. Dans la boîte de dialogue Sélectionner à partir de qui s'affiche, sélectionnez votre projet. Si vous ne trouvez pas votre projet alors que vous connaissez son ID, vous pouvez créer une URL dans votre navigateur au format suivant:

    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 de consentement OAuth, puis sélectionnez le bouton Enregistrer et continuer.
  8. 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 champs d'application 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 toute information supplémentaire demandée sur 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 de l'application que vous fournissez nécessite une validation, vous avez la possibilité de l'envoyer pour validation. Remplissez les champs obligatoires, puis cliquez sur Envoyer pour lancer la procédure de validation.

Une fois votre application envoyée, l'équipe Trust & Safety de Google vous enverra un e-mail avec toutes les informations supplémentaires dont elle a besoin ou les étapes à suivre. Vérifiez vos adresses e-mail dans la section Coordonnées du développeur et l'adresse e-mail d'assistance figurant sur votre écran de consentement OAuth pour toute demande d'informations supplémentaires. Vous pouvez également consulter la page de l'écran d'autorisation OAuth de votre projet pour vérifier son état actuel et si le processus d'examen est suspendu en attendant votre réponse.

Exceptions aux exigences de validation

Si votre application doit être utilisée dans l'un des scénarios décrits dans les sections suivantes, vous n'avez pas besoin de l'envoyer pour examen.

Usage personnel

Par exemple, vous êtes le seul utilisateur de votre application, ou celle-ci n'est utilisée que par un petit nombre d'utilisateurs, que vous connaissez tous personnellement. Vous et votre nombre limité d'utilisateurs pouvez être à l'aise pour passer sur l'écran de l'application non validée et autoriser vos comptes personnels à accéder à votre application.

Projets utilisés dans les niveaux de développement, de test ou de préproduction

Afin de respecter les règles Google OAuth 2.0, nous vous recommandons de disposer de projets différents pour les environnements de test et de production. Nous vous recommandons de n'envoyer votre application pour validation que si vous souhaitez qu'elle soit accessible à 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 conserver le paramètre par défaut Tests État de publication. Ce paramètre signifie que votre application est toujours en développement et n'est disponible que pour les utilisateurs figurant sur votre liste d'utilisateurs de test. Vous devez gérer la liste des comptes Google impliqués dans le développement ou le test de votre application.

Message d'avertissement indiquant que Google n'a pas validé une application en cours de test.
Figure 1. Écran d'avertissement pour les testeurs

Données appartenant au service uniquement

Si votre application utilise un compte de service pour accéder uniquement à 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 faire valider votre application.

Pour comprendre en quoi consistent les comptes de service, consultez la page Comptes de service dans la documentation de Google Cloud. Pour obtenir des instructions sur l'utilisation d'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 Considérations supplémentaires concernant Google Workspace.

Installation au niveau du domaine

Si vous prévoyez que votre application cible uniquement les utilisateurs d'une organisation Google Workspace ou Cloud Identity, et que vous utilisez toujours une installation au niveau du domaine, votre application ne nécessite pas de validation. En effet, une installation au niveau du domaine permet à un administrateur de domaine d'autoriser des applications tierces et internes à accéder aux données de vos utilisateurs. Les administrateurs de l'organisation sont les seuls comptes qui peuvent ajouter l'application à une liste d'autorisation en vue de l'utiliser dans leurs domaines.

Pour savoir comment configurer votre application pour une installation au niveau du domaine, consultez la section Mon application comporte des utilisateurs avec des comptes d'entreprise issus d'un autre domaine Google Workspace.