Vérification du niveau d'accès 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 à votre application dépend principalement de deux facteurs :

1. Le 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 forme physique, 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 d'accéder à ses données, vous utilisez des chaînes appelées scopes pour spécifier le type de données auxquelles vous souhaitez accéder en son nom. Si votre application demande des niveaux d'accès classés comme sensibles ou restreints, vous devez probablement effectuer la procédure de validation, sauf si l'utilisation de votre application est éligible à une exception.

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

Vous devez demander les niveaux d'accès aux données utilisateur les plus restreints nécessaires pour fournir cette fonctionnalité. Par exemple, une application qui ne fait que lire des données ne doit pas demander l'accès en lecture, en écriture et en suppression de contenu lorsqu'un champ d'application plus restreint est disponible pour l'API et ses points de terminaison associés. 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é.

Veillez à tenir compte du temps nécessaire pour effectuer la validation dans votre plan de lancement de votre application ou de toute nouvelle fonctionnalité nécessitant un nouveau champ d'application. La procédure de validation des champs sensibles prend généralement trois à cinq jours ouvrés. Notez que votre application peut être éligible à la validation de la marque, qui est un sous-ensemble de votre demande de validation des niveaux d'accès sensibles.

Comprendre les niveaux d'accès sensibles

Les périmètres sensibles doivent être examinés par Google avant qu'un compte Google puisse accorder l'accès. Les administrateurs d'organisation Google Workspace peuvent restreindre l'accès aux scopes sensibles pour empêcher l'accès par des ID client OAuth que l'organisation ne marque pas explicitement comme fiables.

Comprendre votre utilisation des portées

• Examinez les niveaux d'accès que votre application utilise ou que vous souhaitez utiliser. Pour trouver votre utilisation existante des autorisations, examinez le code source de votre application pour identifier les autorisations envoyées avec les demandes d'autorisation.
• Déterminez que chaque niveau d'accès demandé est nécessaire pour les actions prévues de la fonctionnalité de votre application et qu'il utilise le moindre privilège nécessaire pour fournir la fonctionnalité. Une API Google dispose généralement d'une documentation de référence sur la page Google Developers 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 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 que conformément aux règles de l'API et de la manière que vous indiquez à 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 autorisation, y compris son sensitive or restricted état potentiel.
• Déclarez tous les niveaux d'accès utilisés par votre application dans le Data Access page du fichier Cloud Console. Les niveaux d'accès que vous spécifiez sont regroupés dans les catégories "sensible" ou "restreint" pour mettre en évidence toute validation supplémentaire requise.
• Trouvez le meilleur champ d'application correspondant aux données utilisées par votre intégration, comprenez son utilisation, reconfirmez que tout fonctionne toujours dans un environnement de test, puis préparez-vous à l'envoyer pour vérification.

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

1. Vérifiez que votre application ne relève d'aucun des cas d'utilisation de la section Exceptions aux exigences de validation.
2. Assurez-vous que votre application respecte les exigences en termes de branding des API ou du produit associés. Par exemple, consultez les consignes de branding pour les niveaux d'accès 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 sur la marque figurant 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 fidèlement l'identité de l'application.

Exigences concernant la page d'accueil de l'application

Assurez-vous que votre page d'accueil respecte les exigences 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 Play Store de votre application 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, hébergées dans le même domaine que la page d'accueil de votre application et accessibles via un lien sur l'écran de consentement OAuth de 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 aux données utilisateur Google, les utilise, les stocke ou les partage. Vous devez limiter votre utilisation des données utilisateur Google aux pratiques décrites dans vos règles de confidentialité publiées.

Envoyer votre application pour validation

Un Google Cloud Console projet permet d'organiser toutes vos ressources Cloud Console . Chaque projet comprend un ensemble de comptes Google associés autorisés à effectuer des opérations sur le 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 pour qu'elles soient utilisées par ces clients et configurer un écran d'autorisation OAuth qui s'affiche pour les 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 le Clients page.

Pour demander la validation, 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 dans les services d'API Google.
2. Dans votre Cloud Console, veillez à ce que les rôles de propriétaire et d'éditeur des comptes associés à votre projet soient à jour, ainsi que l'adresse e-mail d'assistance aux utilisateurs et les coordonnées du développeur de l'écran d'autorisation OAuth. Cela permet de s'assurer que les membres concernés de votre équipe sont informés de toute nouvelle exigence.
3. Accédez au Centre de validation OAuth Cloud Console.
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 projet, mais que vous connaissez son ID, vous pouvez créer une URL dans votre navigateur au format suivant :

   https://console.developers.google.com/auth/branding?project=[PROJECT_ID]

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

6. Sélectionnez le bouton 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 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 à 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.
9. Fournissez jusqu'à trois liens vers toute documentation pertinente pour les fonctionnalités associées de votre application.

10. Fournissez toutes les informations supplémentaires demandées sur votre application lors des é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 d'application que vous fournissez nécessite une validation, vous avez la possibilité de soumettre l'application 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 contactera par e-mail pour vous demander des informations supplémentaires ou vous indiquer 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 voir si vous avez reçu 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 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 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 personnes que vous connaissez personnellement. Vous et votre nombre limité d'utilisateurs pouvez être à l'aise avec l'écran "Application non validée" et accorder à vos comptes personnels l'accès à votre application.

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

Pour respecter les règles Google OAuth 2.0, nous vous recommandons d'utiliser des projets différents pour les environnements de test et de production. Nous vous recommandons de ne soumettre votre application à la 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 sur le paramètre par défaut 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 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 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 demander la validation.

Pour comprendre ce que sont les comptes de service, consultez Comptes de service dans la documentation Google Cloud. Pour savoir comment utiliser un compte de service, consultez 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 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 à l'échelle du domaine

Si vous prévoyez que votre application ne cible que les utilisateurs d'une organisation Google Workspace ou Cloud Identity et qu'elle utilise toujours l'installation à l'échelle du domaine, elle n'aura pas besoin d'être validée. 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. Seuls les comptes d'administrateur d'organisation peuvent ajouter l'application à une liste d'autorisation pour l'utiliser dans leurs domaines.

Découvrez comment installer votre application à l'échelle du domaine dans les questions fréquentes. Mon application comporte des utilisateurs disposant de comptes d'entreprise provenant d'un autre domaine Google Workspace.