Respecter les règles OAuth 2.0

Lorsque vous êtes prêt à déployer votre solution implémentée au-delà de votre environnement de développement auprès des 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 vous expliquons comment vous conformer aux problèmes de développeur les plus courants rencontrés lorsque vous préparez votre application pour la production. Vous pouvez ainsi toucher la plus grande audience 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 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 à vérification et donc être soumis à des exigences supplémentaires pour des portées d'API spécifiques, qui peuvent inclure des évaluations de sécurité tierces.

  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 toutes les API utilisées par vos clients.
  4. Vérifiez la configuration de l'écran de consentement OAuth dans le nouveau projet.

Les clients OAuth Google 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 à 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 à ses services ou de nouvelles configurations requises pour votre projet et ses clients. Passez en revue les entrées IAM de votre projet pour vous assurer que les personnes concernées de votre équipe ont accès à la configuration de votre projet pour la modifier ou la consulter. 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 projets disposent d'autorisations pour les actions qui modifient l'état, comme la possibilité de modifier l'écran d'autorisation OAuth de votre projet. Les propriétaires de projets disposant de toutes les autorisations d'éditeur peuvent ajouter ou supprimer des comptes associés au projet, ou le supprimer. Les propriétaires de projet peuvent également fournir du contexte sur les raisons pour lesquelles 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 vous assurer d'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 mises à jour de nos services. Les administrateurs d'une organisation Google Cloud doivent s'assurer qu'un contact accessible est associé à chaque projet de leur organisation. Si nous ne disposons pas d'informations de contact à jour pour votre projet, vous risquez de manquer des messages importants qui nécessitent votre intervention.

Représenter votre identité avec précision

Indiquez un nom d'application valide et, éventuellement, un logo à afficher pour les utilisateurs. Ces informations sur la marque doivent représenter précisément l'identité de votre application. Les informations de branding de l'application sont configurées à partir de l' OAuth.

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 affichées pour les 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 son nom, sa page d'accueil, ses conditions d'utilisation et sa politique de confidentialité, sont présentées aux utilisateurs sur l'écran d'autorisation lorsqu'ils examinent leurs autorisations 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 présentent une fausse identité ou tentent de tromper les utilisateurs.

Ne demandez que les niveaux d'accès 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 un prototype dans votre application afin d'en savoir plus sur les fonctionnalités de l'API. Ces exemples de champs d'application demandent souvent plus d'informations que les besoins d'implémentation finale de votre application, car ils couvrent de manière exhaustive toutes les actions possibles pour une API donnée. 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 pertinentes qui se limitent aux informations essentielles nécessaires à l'implémentation de votre application.

Consultez la documentation de référence des points de terminaison d'API que votre application appelle et notez les champs d'application dont elle a besoin pour accéder aux données pertinentes. Consultez les guides d'autorisation proposés par l'API et décrivez leurs champs d'application plus en détail pour inclure les utilisations les plus courantes. 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 Ne demander que les champs d'application dont vous avez besoin des règles OAuth 2.0, ainsi que la section Demander les autorisations appropriées du règlement relatif aux données utilisateur dans les services d'API Google.

Envoyer des applications de production qui utilisent des champs d'application sensibles ou restreints pour validation

Certains champs d'application sont classés comme"sensibles " ou"restreints" et ne peuvent pas être utilisés dans les applications de production sans examen. Saisissez tous les champs d'application que votre application de production utilise dans sa configuration de l'écran de consentement OAuth. Si votre application de production utilise des champs d'application sensibles ou restreints, vous devez soumettre votre utilisation de ces champs d'application pour validation avant de les inclure dans une requête d'autorisation.

N'utiliser que des domaines que vous possédez

La procédure 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. Consultez la liste des domaines utilisés par votre application, résumée dans la section Domaines autorisés de l'éditeur de l'écran d'autorisation OAuth, et identifiez les domaines que vous ne possédez pas et que vous ne pouvez 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 projet 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 des configurations autorisant l'utilisation de votre propre domaine. Certains fournisseurs proposent de mapper leurs services sur 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 qui utilise OAuth 2.0 doit 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 qu'elle propose. Les utilisateurs existants peuvent consulter la liste des autorisations existantes et visiter 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 des règles de confidentialité et des conditions d'utilisation facultatives. La page d'accueil doit exister sur un domaine validé dont vous êtes propriétaire.

Utiliser des URI de redirection sécurisées 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 de HTTP simple. Google peut refuser les requêtes OAuth qui ne proviennent pas d'un contexte sécurisé ou qui ne se résolvent pas en un contexte sécurisé.

Déterminez quelles applications et scripts tiers peuvent avoir accès aux jetons et aux autres identifiants utilisateur renvoyés sur votre page. Limitez l'accès aux données sensibles avec des emplacements d'URI de redirection limités à la validation et au stockage des données de jeton.

Étapes suivantes

Après vous être assuré que votre application respecte les règles OAuth 2.0 décrites sur cette page, consultez Envoyer une demande de validation de la marque pour en savoir plus sur la procédure de validation.