Respecter les règles OAuth 2.0

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Lorsque vous serez prêt à déployer votre solution mise en œuvre au-delà de votre environnement de développement sur les utilisateurs de votre application, vous devrez peut-être prendre des mesures supplémentaires pour vous conformer aux Règles OAuth 2.0 de Google. Dans ce guide, nous décrivons comment résoudre les problèmes les plus courants rencontrés par les développeurs lorsque vous préparez votre application en production. Vous pouvez ainsi toucher la plus large audience possible avec un nombre d'erreurs limité.

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 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 offrent un environnement de collecte et de stockage de 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 soumis à validation et 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 de votre projet de production.
  3. Activez toutes les API utilisées par vos clients.
  4. Examinez 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 disponibles uniquement pour vous ou votre équipe de développement. Voici quelques exemples:

  • Les serveurs de test de chaque développeur
  • Tester les versions préliminaires de votre application

Tenir à jour une liste de contacts pertinents pour le projet

Google et les API individuelles que vous activez peuvent avoir besoin de vous contacter au sujet des modifications apportées à leurs services ou des nouvelles configurations requises pour votre projet et ses clients. Examinez les listes IAM de votre projet pour vous assurer que les personnes concernées de 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 vous permettant 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 du projet, telles que la possibilité de modifier l'écran d'autorisation OAuth de votre projet. Les propriétaires de projet disposant de toutes les autorisations du rôle Éditeur peuvent ajouter ou supprimer des comptes associés au projet, ou supprimer le projet. Les propriétaires de projet peuvent également expliquer pourquoi les informations de facturation peuvent être définies. Les propriétaires 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 à jour. Vous pouvez ajouter plusieurs comptes pertinents à votre projet pour assurer un accès continu au projet et aux opérations de maintenance associées. Nous envoyons des e-mails à ces comptes lorsque nous recevons des notifications concernant votre projet ou des mises à jour de 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 des coordonnées les plus récentes pour votre projet, vous risquez de passer à côté de messages importants nécessitant votre intervention.

Représentez fidèlement votre identité

Indiquez un nom d'application valide et, éventuellement, un logo à présenter aux utilisateurs. Ces informations sur la marque doivent représenter avec précision l'identité de votre application. Les informations de branding d'application sont configurées à partir du protocole OAuth Consent Screen page.

Pour les applications de production, les informations sur la marque définies dans votre écran d'autorisation OAuth doivent être validées avant de les présenter aux utilisateurs. Les utilisateurs sont plus susceptibles d'accorder l'accès à votre application une fois la validation de la marque terminée. Les informations de base sur l'application, y compris le nom de l'application, sa page d'accueil, ses conditions d'utilisation et ses règles de confidentialité, sont présentées aux utilisateurs sur l'écran des subventions lorsqu'ils consultent leurs subventions existantes ou aux administrateurs Google Workspace qui examinent l'utilisation des applications par leur organisation.

Google peut révoquer ou suspendre l'accès aux services d'API Google ainsi qu'à d'autres produits et services Google pour les applications qui dénaturent leur identité ou tentent de tromper les utilisateurs.

N'envoyez 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 afin d'en savoir plus sur ses caractéristiques et son fonctionnement. Ces exemples de champs d'application demandent souvent plus d'informations que les implémentations finales de vos applications, car ils fournissent une couverture complète de toutes les actions possibles pour une API spécifique. Par exemple, le champ d'application de l'exemple peut demander des autorisations de lecture, d'écriture et de suppression, tandis que votre application ne requiert que des autorisations de lecture. Demandez des autorisations pertinentes 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 de l'API que votre application appelle, et notez les champs d'application requis 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 afin d'inclure l'utilisation la plus courante. Choisissez l'accès minimal aux données dont votre application a besoin pour bénéficier des fonctionnalités associées.

Pour en savoir plus sur cette exigence, consultez la section Champs d'application de la requête uniquement dans les règles OAuth 2.0, ainsi que la section Demander des autorisations pertinentes dans le règlement sur les données utilisateur des services d'API Google.

Envoyer des applications de production qui utilisent des niveaux d'accès sensibles ou restreints pour la validation

Certains champs d'application sont classés comme sensibles 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 d'écran de consentement OAuth. Si votre application de production utilise des champs d'application sensibles ou restreints, vous devez les utiliser pour validation avant de les inclure dans une requête d'autorisation.

Utiliser uniquement les domaines dont vous êtes propriétaire

Le processus de validation de l'écran d'autorisation OAuth de Google nécessite la validation 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. Passez en revue la liste des domaines utilisés par votre application, récapitulée dans la section Domaines autorisés de l'éditeur d'écran de consentement OAuth, et identifiez les domaines dont vous n'êtes pas propriétaire et que vous ne pourriez donc pas valider. Pour valider la propriété des domaines autorisés de votre projet, utilisez la Google Search Console. Utilisez un compte Google associé à votre API Console projet en tant que propriétaire ou éditeur.

Si votre projet utilise un fournisseur de services avec un domaine commun, nous vous recommandons d'activer les configurations qui autorisent 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

Chaque application de production utilisant OAuth 2.0 doit 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 ses fonctionnalités et son fonctionnement. Les utilisateurs existants peuvent consulter leur liste d'autorisations et accéder à la page d'accueil de votre application pour se rappeler 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 HTTP brut. Google peut refuser les requêtes OAuth qui ne proviennent pas d'un contexte sécurisé ou qui ne sont pas résolues dans ce contexte.

Déterminez quels applications et scripts tiers peuvent accéder aux jetons et aux autres identifiants utilisateur qui reviennent sur votre page. Limitez l'accès aux données sensibles à l'aide d'emplacements d'URI de redirection limités à la validation et au stockage des données par jeton.

Étapes suivantes

Après avoir vérifié que votre application est conforme aux règles OAuth 2.0 sur cette page, consultez Envoyer la demande de validation de la marque pour en savoir plus sur le processus de validation.