Certaines API Google (celles qui acceptent les niveaux d'accès sensibles ou restreints ) sont soumises à des exigences pour les applications qui demandent l'autorisation d'accéder aux données des consommateurs. Ces exigences supplémentaires pour les niveaux d'accès restreintsobligent une application à démontrer qu'elle est un type d'application autorisé et à se soumettre à des examens supplémentaires, y compris une éventuelle évaluation de sécurité.
L'applicabilité des niveaux d'accès restreints dans une API dépend principalement du degré 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 niveaux d'accès 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 niveaux d'accès sensibles ou restreints , vous devez suivre la procédure de validation, sauf si l'utilisation de votre application est éligible à une exception.
Les niveaux d'accès restreints sont moins nombreux que les niveaux d'accès sensibles. La FAQ sur la validation de l'API OAuth contient la liste actuelle des niveaux d'accès sensibles et restreints. Ces niveaux d'accès offrent un accès étendu aux données utilisateur Google et vous obligent à suivre une procédure de validation des niveaux d'accès avant de demander les niveaux d'accès à 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 niveaux d'accès d'API spécifiques ou la page Google Developers spécifique au produit. Si vous stockez ou transmettez des données de niveau d'accès restreint sur des serveurs, vous devez effectuer une évaluation de sécurité.
Comprendre les niveaux d'accès restreints
Si votre application demande des niveaux d'accès restreints et n'est pas éligible à une exception, vous devez respecter les Exigences supplémentaires pour les niveaux d'accès d'API spécifiques du Règlement sur les données utilisateur dans les services d'API Google ou les exigences spécifiques au produit sur la page Google Developers du produit, ce qui nécessite une procédure d'examen plus approfondie.
Comprendre votre utilisation des niveaux d'accès
- Vérifiez les niveaux d'accès que votre application utilise ou que vous souhaitez utiliser. Pour connaître votre utilisation actuelle des niveaux d'accès, examinez le code source de votre application pour détecter les niveaux d'accès envoyés avec les demandes d'autorisation.
- Vérifiez 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 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 que votre application appelle, consultez la documentation de référence de ces points de terminaison. Par exemple, pour une application qui n'utilise les API Gmail que pour envoyer occasionnellement des e-mails au nom d'un utilisateur, ne demandez pas le niveau d'accès qui fournit un accès complet aux données de messagerie de l'utilisateur.
- 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 dont vous les 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 niveau d'accès, y compris son état potentiel sensible ou restreint.
- Déclarez tous les niveaux d'accès utilisés par votre application sur la page Accès aux données de Cloud Console. Les niveaux d'accès que vous spécifiez sont regroupés dans des catégories sensibles ou restreintes pour mettre en évidence toute validation supplémentaire requise.
- Recherchez le meilleur niveau d'accès correspondant aux données utilisées par votre intégration, comprenez son utilisation, vérifiez que tout fonctionne toujours dans un environnement de test, puis préparez-vous à envoyer votre demande de 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 niveau d'accès. L'une de ces exigences supplémentaires se produit si l'application accède aux données utilisateur Google à partir d'un serveur ou via un serveur. Dans ce cas, le système doit faire l'objet d'une évaluation de sécurité annuelle 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 d'abord passer 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 approuvée de l'écran de consentement OAuth.
Types d'application autorisés
Certains types d'applications peuvent accéder à des niveaux d'accès restreints pour chaque produit. Vous pouvez trouver les types d'applications sur la page Google Developers spécifique au produit (par exemple, le Règlement sur 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 ne sélectionner aucune option pour la question Quelles fonctionnalités utiliserez-vous ? lorsque vous envoyez l'application pour validation. L'équipe de validation de l'API Google déterminera alors le type d'application.
Security assessment
Toutes les applications qui demandent l'accès aux données restreintes des utilisateurs Google et qui ont la possibilité d'accéder aux données à partir d'un serveur tiers ou via un serveur tiers doivent passer une évaluation de sécurité réalisée par les é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 en mesure de gérer les données de manière sécurisée et de supprimer les données utilisateur à la demande d'un utilisateur.
Pour standardiser notre évaluation de 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 à tous les niveaux d'accès restreints validés, les applications doivent être revalidées pour la conformité et passer une évaluation de 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 niveau d'accès restreint, elle devra peut-être être réévaluée pour couvrir le niveau d'accès supplémentaire s'il n'a pas été 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 Cloud Console en tant que propriétaire ou éditeur. Il est également utile de tenir à jour les adresses e-mail d'assistance utilisateur et de contact du développeur spécifiées sur la page Branding OAuth de la console Google Cloud.
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 :
- 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 de branding pour les niveaux d'accès 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 de 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 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, hébergées dans le même domaine que la page d'accueil de votre application et liées à l'écran de consentement OAuth de la console Google API. 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 comment votre application accède aux données utilisateur 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 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 de la marque
Un projet de console Google Cloud organise toutes vos ressources de console Cloud. Un projet comprend un ensemble de comptes Google associés qui sont 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 pour qu'elles soient utilisées par ces clients et configurer un écran de consentement 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 sur la page "Clients".
Pour envoyer votre demande de validation, 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.
- Conservez 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 votre écran d'autorisation OAuth, dans votre Cloud Console. Cela permet de s'assurer que les bons membres de votre équipe sont informés de toute nouvelle exigence.
- Accédez à la page Branding OAuth de Cloud Console.
- 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 :
https://console.developers.google.com/auth/branding?project=[PROJECT_ID]
- Sur la page Branding , fournissez les informations de branding de votre application, y compris le nom de l'application, le logo, les coordonnées du développeur et les liens pertinents. Toutes les modifications que vous apportez sont enregistrées en tant que Branding brouillon.
- Cliquez sur le bouton Valider le branding pour lancer la procédure d'évaluation. L'examen automatisé prend généralement quelques minutes.
- Une fois l'évaluation terminée, vérifiez l'état. En cas de réussite, l'état passe à Prêt à être publié. Si la validation automatisée échoue, vous pouvez voir les problèmes détectés et les résoudre ou demander un examen manuel.
- Cliquez sur le bouton Publier le branding pour rendre le nouveau branding actif.
- Si votre application nécessite également une validation pour les niveaux d'accès sensibles ou restreints, accédez au Centre de validation OAuth pour suivre l'état de l'accès aux données et fournir toute information supplémentaire demandée, comme une vidéo de démonstration. Notez que vous devez avoir un état de branding publié avant de pouvoir demander la validation de l'accès aux données.
- Utilisez le bouton Ajouter ou supprimer des niveaux d'accès pour déclarer tous les niveaux d'accès demandés par votre application. Un ensemble initial de niveaux d'accès nécessaires pour Google Sign-In est prérempli dans la section Niveaux d'accès non sensibles. Les niveaux d'accès ajoutés sont classés comme non sensibles, sensitive, or restricted .
- Fournissez jusqu'à trois liens vers toute documentation pertinente pour les fonctionnalités associées de votre application.
- 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.
Une fois que vous avez publié votre branding ou envoyé une demande d'accès aux données, l'équipe Trust & Safety de Google peut vous contacter 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 de consentement OAuth pour les demandes d'informations supplémentaires. Vous pouvez également consulter les pages Branding ou Centre de validation de votre projet pour confirmer l'état actuel de l'examen de votre projet, y compris si la procédure d'examen est suspendue 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
Un cas d'utilisation se présente si vous êtes le seul utilisateur de votre application ou si votre application n'est utilisée que par quelques utilisateurs que vous connaissez personnellement. Vous et votre nombre limité d'utilisateurs pouvez accepter de passer l'écran "Application non validée" et d'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'avoir différents projets pour les environnements de test et de production. Nous vous recommandons de n'envoyer votre application pour validation que si vous souhaitez la rendre disponible à tout utilisateur 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 disponible que 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 le test de votre application.
Données appartenant uniquement au service
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 (liée à un compte Google), vous n'avez pas besoin de l'envoyer pour validation.
Pour comprendre ce que sont 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 section 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 personnes de votre organisation Google Workspace ou Cloud Identity organization. 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 Considérations supplémentaires pour Google Workspace.
- Apprenez-en 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 cible que les utilisateurs d'une organisation Google Workspace ou Cloud Identity et qu'elle utilise toujours l'installation au niveau du domaine, votre application n'aura pas besoin de validation de la marque. Toutefois, si votre application utilise des niveaux d'accès restreints ou sensibles, la validation de l'application est requise. 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 de l'organisation peuvent ajouter l'application à une liste d'autorisation pour une utilisation dans leurs domaines.
Découvrez comment faire de votre application une installation au niveau du domaine dans la FAQ Mon application a des utilisateurs disposant de comptes d'entreprise provenant d'un autre domaine Google Workspace.