Lorsque vous êtes prêt à déployer la solution implémentée au-delà de votre environnement de développement pour les utilisateurs de votre application, vous devrez peut-être prendre des mesures supplémentaires pour respecter les règles OAuth 2.0 de Google. Ce guide explique comment mettre en conformité les développeurs avec les problèmes les plus courants rencontrés lorsque vous préparez une application pour la production. Vous pouvez ainsi toucher l'audience la plus large possible avec un nombre d'erreurs limité.
- Utiliser des projets distincts pour les tests et la production
- Tenir une liste des contacts pertinents pour le projet
- Indiquez votre identité avec précision
- Ne demandez que les champs d'application dont vous avez besoin
- Envoyer à des fins de validation des applications de production utilisant des niveaux d'accès sensibles ou restreints
- N'utilisez que des domaines dont vous êtes le propriétaire
- Héberger une page d'accueil pour les applications de production
- Utiliser des URI de redirection sécurisés et des origines JavaScript
Utiliser des projets distincts pour les tests et la production
Les règles OAuth de Google nécessitent des projets distincts pour les tests et la production. Certaines règles et exigences ne s'appliquent qu'aux applications de production. Vous devrez peut-être créer et configurer un projet distinct incluant des clients OAuth correspondant à la version de production de votre application, disponible pour tous les comptes Google.
Les clients Google OAuth utilisés en production offrent un environnement de collecte et de stockage des données plus stable, prévisible et sécurisé que les clients OAuth similaires qui testent ou déboguent la même application. Votre projet de production peut être envoyé pour validation et est donc soumis à des exigences supplémentaires pour des champs d'application d'API spécifiques, qui peuvent inclure des évaluations de sécurité tierces.
- Go to the Google API Console. Click Create project, enter a name, and click Create.
- Examinez les clients OAuth de ce projet qui pourraient être associés à votre niveau de test. Le cas échéant, créez des clients OAuth similaires pour les clients de production dans votre projet de production.
- Activez les API utilisées par vos clients.
- Vérifiez la configuration de l'écran de consentement OAuth dans le nouveau projet.
Les clients Google OAuth utilisés en production ne doivent pas contenir d'environnements de test, d'URI de redirection ni d'origines JavaScript accessibles uniquement à vous ou à votre équipe de développement. Voici quelques exemples:
- Les serveurs de test de développeurs individuels
- Versions de test ou préliminaires de votre application
Tenir une liste des contacts pertinents pour le projet
Google et les différentes API que vous activez peuvent avoir besoin de vous contacter au sujet des modifications apportées à ses services ou des nouvelles configurations requises pour votre projet et ses clients. Examinez les listes IAM de votre projet pour vous assurer que les membres pertinents de votre équipe sont autorisés à modifier ou à consulter la configuration de votre projet. Ces comptes peuvent également recevoir des e-mails concernant les modifications requises pour votre projet.
Un rôle contient un ensemble d'autorisations qui vous permet d'effectuer des actions spécifiques sur les ressources du projet. Les éditeurs de projet sont autorisés à effectuer des actions qui modifient l'état du projet, comme modifier l'écran de consentement OAuth de votre projet. Les propriétaires de projet qui disposent de toutes les autorisations de modification peuvent ajouter ou supprimer des comptes associés au projet, ou le supprimer. Les propriétaires de projet peuvent également expliquer pourquoi des informations de facturation peuvent être définies. Les propriétaires de projet peuvent configurer les informations de facturation d'un projet qui utilise des API payantes.
Les propriétaires et les éditeurs du projet doivent être tenus informés. Vous pouvez ajouter plusieurs comptes pertinents à votre projet pour garantir un accès continu au projet et la maintenance associée. Nous envoyons des e-mails à ces comptes lorsque nous recevons des notifications concernant votre projet ou des modifications apportées à nos services. Les administrateurs d'organisation Google Cloud doivent s'assurer qu'un contact accessible est associé à chaque projet de leur organisation. Si nous ne disposons pas de coordonnées à jour pour votre projet, vous risquez de passer à côté de messages importants qui nécessitent votre action.
Représenter votre identité avec précision
Indiquez un nom d'application valide et, éventuellement, un logo à afficher aux utilisateurs. Les informations sur la marque doivent exprimer avec précision l'identité de votre application. Les informations sur le branding de l'application sont configurées à partir de l'OAuth Consent Screen page.
Pour les applications de production, les informations sur la marque définies dans votre écran de consentement OAuth doivent être validées avant d'être présentées aux utilisateurs. Les utilisateurs sont plus susceptibles d'accorder l'accès à votre application une fois qu'elle a validé sa marque. Des informations de base sur la candidature, y compris le nom de l'application, la page d'accueil, les conditions d'utilisation et les règles de confidentialité, sont présentées aux utilisateurs sur l'écran de demande d'autorisation lorsqu'ils examinent leurs subventions existantes, ou aux administrateurs Google Workspace qui examinent l'utilisation de l'application par leur organisation.
Google peut révoquer ou suspendre l'accès aux services d'API Google et à d'autres produits et services Google pour les applications qui présentent de façon trompeuse leur identité ou tentent de tromper les utilisateurs.
Ne demandez que les champs d'application dont vous avez besoin
Au cours du développement de votre application, vous avez peut-être utilisé un exemple de champ d'application fourni par l'API pour créer une démonstration de faisabilité au sein de votre application. Vous pouvez ainsi en savoir plus sur les caractéristiques et le fonctionnement de l'API. Ces exemples de champs d'application demandent souvent plus d'informations que la mise en œuvre finale nécessaire de votre application, car ils offrent une couverture complète de toutes les actions possibles pour une API spécifique. Par exemple, l'exemple de champ d'application peut demander des autorisations de lecture, d'écriture et de suppression alors que votre application n'a besoin que d'autorisations de lecture. Demandez les autorisations appropriées qui sont limitées aux informations critiques nécessaires à la mise en œuvre de votre application.
Consultez la documentation de référence sur les points de terminaison d'API appelés par votre application et notez les champs d'application dont ils ont besoin pour accéder aux données pertinentes dont votre application a besoin. Consultez les guides d'autorisation proposés par l'API et décrivez leurs champs d'application plus en détail pour inclure l'utilisation la plus courante. Choisissez l'accès aux données le plus minimal dont votre application a besoin pour alimenter les fonctionnalités associées.
Pour en savoir plus sur cette exigence, consultez la section Uniquement les champs d'application des requêtes dont vous avez besoin des règles OAuth 2.0, ainsi que la section Demander les autorisations pertinentes du règlement sur les données utilisateur dans les services d'API Google.
Envoyer à des fins de validation des applications de production utilisant des niveaux d'accès sensibles ou restreints
Certains niveaux d'accès sont classés comme"sensibles " ou"limités" et ne peuvent pas être utilisés dans les applications de production sans examen. Saisissez tous les champs d'application utilisés par votre application de production dans sa configuration de l'écran de consentement OAuth. Si votre application de production utilise des niveaux d'accès sensibles ou restreints, vous devez faire valider votre utilisation de ces champs d'application avant de les inclure dans une demande d'autorisation.
N'utilisez que des domaines dont vous êtes le propriétaire
Le processus de validation de l'écran de consentement OAuth de Google nécessite de valider tous les domaines associés à la page d'accueil, aux règles de confidentialité, aux conditions d'utilisation, aux URI de redirection ou aux origines JavaScript autorisées de votre projet. Examinez la liste des domaines utilisés par votre application, résumée dans la section Domaines autorisés de l'éditeur d'écran de consentement OAuth, et identifiez tous les domaines qui ne vous appartiennent pas et ne peuvent donc pas être validés. Pour valider la propriété des domaines autorisés de votre projet, utilisez la Google Search Console. Utilisez un compte Google associé à votre projet API Console en tant que propriétaire ou éditeur.
Si votre projet fait appel à un fournisseur de services avec un domaine commun et partagé, nous vous recommandons d'activer des configurations autorisant l'utilisation de votre propre domaine. Certains fournisseurs proposent de mapper leurs services à un sous-domaine d'un domaine que vous possédez déjà.
Héberger une page d'accueil pour les applications de production
Toutes les applications de production qui utilisent OAuth 2.0 doivent disposer d'une page d'accueil accessible au public. Les utilisateurs potentiels de votre application peuvent consulter la page d'accueil pour en savoir plus sur les fonctionnalités proposées par l'application. Les utilisateurs existants peuvent consulter la liste des subventions existantes et consulter la page d'accueil de votre application pour se rappeler qu'ils continuent d'utiliser votre offre.
La page d'accueil de votre application doit inclure une description de ses fonctionnalités, ainsi que des liens vers des règles de confidentialité et des conditions d'utilisation facultatives. La page d'accueil doit exister sur un domaine validé qui vous appartient.
Utiliser des URI de redirection sécurisés et des origines JavaScript
Les clients OAuth 2.0 pour les applications Web doivent sécuriser leurs données à l'aide d'URI de redirection HTTPS et d'origines JavaScript, et non en utilisant le protocole HTTP simple. Google peut rejeter les requêtes OAuth qui ne proviennent pas d'un contexte sécurisé ou ne mènent pas à un contexte sécurisé.
Déterminez quelles applications et scripts tiers pourraient avoir accès aux jetons et autres identifiants utilisateur qui renvoient sur votre page. Limitez l'accès aux données sensibles à l'aide d'emplacements d'URI de redirection qui se limitent à la vérification et au stockage des données des jetons.
Étapes suivantes
Après vous être assuré que votre application respecte les règles OAuth 2.0 figurant sur cette page, consultez Envoyer pour validation de la marque pour en savoir plus sur la procédure de validation.