Validation du champ d'application sensible

Si votre application demande l'autorisation d'utiliser les API Google pour accéder aux données des utilisateurs Google, vous devrez peut-être suivre une procédure de validation avant de rendre votre application publique pour la première fois.

L'application de cette exigence dépend principalement de deux facteurs:

1. Type de données utilisateur auxquelles vous accédez : informations de profil public, entrées d'agenda, fichiers dans Drive, certaines données de santé et de remise en forme, etc.
2. Le niveau d'accès dont vous avez besoin (lecture seule, lecture et écriture, etc.)

Lorsque vous utilisez OAuth 2.0 pour obtenir l'autorisation d'un compte Google à accéder à leurs données, vous devez utiliser des chaînes appelées champs d'application pour spécifier le type de données auquel vous souhaitez accéder en leur nom. Si votre application demande des niveaux d'accès catégorisés comme sensibles ou limités, vous devrez probablement suivre le processus de validation, sauf si l'utilisation de votre application remplit les conditions requises.

Exemples de champs d'application sensibles : lecture d'événements stockés dans Google Agenda, stockage d'un nouveau contact dans Google Contacts ou suppression d'une vidéo YouTube. Pour plus d'informations sur les champs d'application disponibles et leurs classifications, consultez la documentation de référence des points de terminaison d'API appelés par votre application et tout guide d'autorisation associé publié pour l'API.

Vous devez demander les niveaux d'accès nécessitant le moins d'accès possible aux données utilisateur nécessaires pour fournir cette fonctionnalité. Par exemple, une application qui ne lit que les données ne doit pas demander l'accès en lecture, en écriture ou à la suppression de contenu lorsqu'un champ d'application plus restreint est disponible pour l'API et les points de terminaison associés. Les données que vous recevez d'une API Google ne doivent être utilisées que dans le respect de ses règles et de la manière dont vous les représentez dans les actions de votre application et dans vos règles de confidentialité.

Tenez compte du temps nécessaire pour terminer la validation de votre plan de lancement pour votre application ou de toute nouvelle fonctionnalité nécessitant un nouveau champ d'application. Le processus de validation des champs d'application sensibles prend généralement trois à cinq jours ouvrés. Notez que votre application peut être éligible à la validation de la marque en tant que sous-ensemble de votre demande de validation de niveau d'accès sensible.

Comprendre les niveaux d'accès sensibles

Les champs d'application sensibles doivent être examinés par Google avant de pouvoir accorder l'accès à un compte Google. Les administrateurs de l'organisation Google Workspace peuvent restreindre l'accès aux champs d'application sensibles pour empêcher tout ID client OAuth que l'organisation n'a pas explicitement marqué comme étant de confiance.

Comprendre l'utilisation de votre champ d'application

• Examinez les champs d'application utilisés par votre application ou que vous souhaitez utiliser. Pour connaître l'utilisation des champs d'application existants, examinez le code source de votre application afin de détecter les portées envoyées avec les requêtes d'autorisation.
• Déterminez que chaque champ d'application demandé est nécessaire pour effectuer les actions prévues par la fonctionnalité de votre application et utilise le minimum de droits nécessaire pour la fournir. Une API Google dispose généralement d'une documentation de référence sur ses produits (sur la page Google Developers), qui inclut le niveau d'accès requis pour appeler le point de terminaison ou des propriétés spécifiques. 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 de ces points de terminaison.
• Les données que vous recevez d'une API Google ne doivent être utilisées qu'en conformité avec les règles de l'API et de la façon dont vous les représentez 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 sur la page de configuration de l'écran de consentement OAuth de API Console. Les champs d'application que vous spécifiez sont regroupés dans des catégories sensibles ou limitées pour mettre en évidence toute validation supplémentaire requise.
• Recherchez le champ d'application qui correspond le mieux aux données utilisées par votre intégration, comprenez son utilisation, confirmez que tout fonctionne toujours dans un environnement de test, puis préparez-vous à envoyer la demande de validation.

É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 afin de valider leur marque:

1. Vérifiez que votre application ne correspond à aucun des cas d'utilisation décrits dans la section Exceptions aux exigences de validation.
2. Assurez-vous que votre application est conforme aux 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 le compte Google associé à votre projet API Console en tant que propriétaire ou éditeur.
4. Assurez-vous que toutes les informations de branding sur l'écran de consentement OAuth, comme 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 remplit les conditions suivantes:

• Votre page d'accueil doit être accessible publiquement, 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 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 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 les conditions d'utilisation facultatives.
• Ces règles de confidentialité doivent indiquer la manière dont votre application accède aux données utilisateur Google, les utilise, les partage ou les partage. Vous devez limiter votre utilisation des données utilisateur de Google aux pratiques mentionnées dans vos règles de confidentialité publiées.

Envoyer votre application pour validation

Un Google API Console projet organise toutes vos API Console ressources. Un projet contient un ensemble de comptes Google associés autorisés à effectuer des opérations de projet, un ensemble d'API activées, ainsi que les paramètres de facturation, d'authentification et de surveillance de ces API. Par exemple, un projet peut contenir un ou plusieurs clients OAuth, configurer les API à utiliser par ces clients et configurer un écran d'autorisation OAuth présenté aux utilisateurs avant d'autoriser l'accès à votre application.

Si l'un de vos clients OAuth n'est pas prêt pour la production, nous vous conseillons de le supprimer du projet qui demande une validation. Vous pouvez le faire dans Google API Console.

Pour demander une validation, procédez comme suit:

1. Assurez-vous que votre application est conforme aux Conditions d'utilisation des API Google et aux Règles sur les données utilisateur pour les services des API Google.
2. Tenez à jour les rôles de propriétaire et d'éditeur des comptes associés à votre projet, ainsi que les adresses e-mail de l'assistance utilisateur et les coordonnées du développeur de l'écran de consentement OAuth dans votre API Console. De cette façon, les nouveaux membres de votre équipe seront informés des nouvelles exigences.
3. Accédez à l' 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, mais 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 d'écran de consentement OAuth, puis sélectionnez le bouton Enregistrer et continuer.
8. Utilisez le bouton Ajouter ou supprimer des habilitations pour déclarer tous les habilitations demandées 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 concernant les fonctionnalités associées de votre application.

10. Fournissez les informations supplémentaires requises concernant votre application dans les étapes suivantes.

    1. Prepare a detailed justification for each requested sensitive scope, as well as an explanation for why a narrower scope isn't sufficient. For example: "My app will use https://www.googleapis.com/auth/calendar to show a user's Google calendar data on the scheduling screen of my app. This lets users manage their schedules through my app and sync the changes with their Google calendar."

    2. 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 its 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 scope that you request.
11. Si la configuration que vous fournissez nécessite une validation, vous pouvez la soumettre 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 Google vous enverra par e-mail les informations supplémentaires dont vous avez 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 de votre écran d'autorisation OAuth pour les demandes d'informations supplémentaires. Vous pouvez également afficher la page d'écran de consentement OAuth de votre projet pour vérifier l'état d'examen actuel de votre projet. Vous pouvez par exemple vous assurer que le processus d'examen est en veille en attendant votre réponse.

Exceptions aux exigences de validation

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

Usage personnel

C'est par exemple le cas si vous êtes le seul utilisateur de votre application ou si votre application n'est utilisée que par quelques utilisateurs qui vous sont connus personnellement. Vous et votre nombre limité d'utilisateurs pouvez vous familiariser avec l'écran d'une 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 OAuth 2.0 de Google, nous vous recommandons de définir des projets différents pour les environnements de test et de production. Nous vous recommandons de soumettre votre application à des fins de validation uniquement 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 l'état de publication dans le paramètre par défaut de test. Ce paramètre signifie que votre application est toujours en développement et qu'elle n'est accessible qu'aux personnes 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.

Données du service uniquement

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

Pour comprendre ce qu'est un compte de service, consultez la page Comptes de service dans la documentation de Google Cloud. Pour savoir comment utiliser un compte de service, consultez Utiliser OAuth 2.0 pour l'authentification serveur à serveur.

Ils sont réservés à un usage interne

Cela signifie que seuls les membres de votre organisation Google Workspace ou Cloud Identity utilisent l'application. Le projet doit appartenir à l'organisation, et son écran de consentement OAuth doit être configuré pour un type d'utilisateur interne. Dans ce cas, un administrateur de l'organisation peut avoir besoin de l'approbation de votre application. Pour en savoir plus, consultez Remarques supplémentaires concernant Google Workspace.

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

Installation à l'échelle du domaine

Si votre application cible uniquement les utilisateurs d'une organisation Google Workspace ou Cloud Identity et que vous utilisez toujours l'installation à l'échelle du domaine, vous n'aurez pas besoin de valider l'application. 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 autorisés à ajouter l'application à une liste d'autorisation pour une utilisation au sein de leur domaine.

Découvrez comment configurer votre application en tant qu'installation à l'échelle du domaine dans les questions fréquentes : Mon application comprend des utilisateurs possédant un compte d'entreprise sur un autre domaine Google Workspace.