Respectez les règles OAuth 2.0

Lorsque vous êtes prêt à déployer la solution mise en œuvre 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. Dans ce guide, nous expliquons comment respecter les problèmes les plus courants rencontrés par les développeurs lorsque vous préparez votre 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

Les règles OAuth de Google exigent 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 les clients OAuth correspondant à la version de production de votre application disponible pour tous les comptes Google.

Les clients Google OAuth utilisés en production contribuent à fournir 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 doit donc être soumis à des exigences supplémentaires pour des champs d'application d'API spécifiques, qui peuvent inclure des évaluations de sécurité tierces.

  1. Go to the Google API Console. Click Create project, enter a name, and click Create.
  2. 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.
  3. Activez les API utilisées par vos clients.
  4. 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 versions 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 de modifications apportées à ses services ou de nouvelles configurations requises pour votre projet et ses clients. Examinez les listes IAM de votre projet pour vous assurer que les personnes concernées dans votre équipe sont autorisées à modifier ou à afficher 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 disposent des autorisations nécessaires pour effectuer des actions qui modifient l'état de votre projet, comme modifier l'écran de consentement OAuth de votre projet. Les propriétaires de projet disposant 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 changements apportés à nos services. Les administrateurs d'organisation Google Cloud doivent s'assurer qu'un contact joignable est associé à chaque projet de leur organisation. Si nous ne disposons pas de coordonnées à jour pour votre projet, vous risquez de manquer des messages importants nécessitant votre action.

Indiquez une identité fidèle

Fournissez un nom d'application valide et, éventuellement, un logo à présenter aux utilisateurs. Les informations sur la marque doivent représenter avec précision l'identité de votre application. Les informations de branding de l'application sont configurées à partir de l'authentification 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 de pouvoir être présentées aux utilisateurs. Les utilisateurs sont plus susceptibles d'accorder l'accès à votre application une fois que celle-ci a terminé la validation de la marque. Les informations de base de l'application, y compris le nom de l'application, la page d'accueil, les conditions d'utilisation et les règles de confidentialité, sont visibles par les utilisateurs sur l'écran de subvention lorsqu'ils examinent leurs subventions existantes, ou par les 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

Lors 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 pourrez 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 des besoins 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 ne nécessite que des autorisations de lecture. Demandez les autorisations appropriées qui se limitent aux informations critiques nécessaires à la mise en œuvre de votre application.

Consultez la documentation de référence sur les points de terminaison de l'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 tous 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 le niveau d'accès aux données le plus faible 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 de requête dont vous avez besoin des règles OAuth 2.0, ainsi que la section Demander les autorisations pertinentes des règles sur les données utilisateur dans les services d'API Google.

Envoyer à des fins de validation des applications de production dont les niveaux d'accès sont sensibles ou restreints

Certains champs d'application sont classés comme"sensibles " ou"limités" et ne peuvent pas être utilisés dans les applications de production sans examen préalable. 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 champs d'application 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 la vérification de tous les domaines associés à la page d'accueil, aux règles de confidentialité, aux conditions d'utilisation, aux URI de redirection autorisés 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 qui 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 utilise un fournisseur de services avec un domaine commun et partagé, nous vous recommandons d'activer les 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 publiquement. 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 accéder à la page d'accueil de votre application pour se rappeler qu'ils continuent à utiliser votre offre.

La page d'accueil de votre application doit inclure une description de ses fonctionnalités, ainsi que des liens vers les 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 du protocole HTTP simple. Google peut rejeter les requêtes OAuth qui ne proviennent pas d'un contexte sécurisé ou ne renvoient pas vers un contexte sécurisé.

Identifiez les applications et scripts tiers qui 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 de cette page, consultez Envoyer pour validation de la marque pour en savoir plus sur la procédure de validation.