Respecter les règles OAuth 2.0

Ce guide explique comment résoudre les problèmes les plus courants rencontrés par les développeurs lors de la préparation de leur application pour la production.

Présentation

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 vous conformer aux Règles OAuth 2.0 de Google. Dans ce guide, nous expliquons comment résoudre les problèmes les plus courants rencontrés par les développeurs lors de la préparation de leur application pour la production. Cela vous permet de toucher l'audience la plus large possible avec un minimum d'erreurs.

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 des clients OAuth correspondant à la version en production de votre application disponible pour tous les comptes Google.

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

  1. Accédez à la console Google APIs. Cliquez sur Créer un projet, saisissez un nom, puis cliquez sur Créer.
  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 pour le nouveau projet sur la page "Branding" de la console Cloud.

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 par vous ou votre équipe de développement. Voici quelques exemples :

  • Les serveurs de test des développeurs individuels
  • Versions de test ou 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 de modifications apportées à leurs 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 de votre équipe ont accès à la configuration de votre projet pour la modifier ou l'afficher. 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, comme modifier l'écran de consentement OAuth de votre projet. Les propriétaires de projet disposant de toutes les autorisations d'éditeur peuvent ajouter ou supprimer des comptes associés au projet, ou supprimer le projet. Les propriétaires de projet peuvent également fournir des informations sur les raisons pour lesquelles les 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 de 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 des notifications concernant votre projet ou des mises à jour de nos services sont disponibles. Les administrateurs de l'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 ne pas recevoir de messages importants nécessitant une action de votre part.

Présenter votre identité de manière exacte

Indiquez un nom d'application valide et, si vous le souhaitez, un logo à présenter aux utilisateurs. Ces informations sur la marque doivent représenter fidèlement l'identité de votre application. Les informations de branding de l'application sont configurées sur la page de branding 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 présentées 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, qui incluent son nom, sa page d'accueil, ses conditions d'utilisation et ses règles 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 de l'application par leur organisation.

Google peut révoquer ou suspendre l'accès aux Google APIs et à d'autres produits et services Google pour les applications qui effectuent des déclarations trompeuses ou déceptives sur 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é 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 ce dont l'implémentation finale de votre application a besoin, 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 requises pour implémenter votre application.

Consultez la documentation de référence des points de terminaison de l'API appelés par votre application et notez les niveaux d'accès 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 plus en détail leurs champs d'application 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 Ne demandez que les champs d'application dont vous avez besoin des règles OAuth 2.0, ainsi que la section Demander les autorisations appropriées des règles relatives aux données utilisateur des services d'API Google.

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

La fonctionnalité Se connecter avec Google ne demande pas de niveaux d'accès sensibles ni restreints lors de l'authentification d'un utilisateur. Si votre application utilise la fonctionnalité Se connecter avec Google uniquement pour l'authentification, vous devez l'envoyer pour validation de la marque. Vous pouvez envoyer une demande de validation dans la console Google Cloud depuis la page "Branding". Cette validation est nécessaire pour afficher les éléments distinctifs de l'application (y compris le nom, le logo, les règles de confidentialité, les conditions d'utilisation et les champs d'application) sur l'écran de consentement.

Nous vous recommandons vivement de respecter les consignes officielles relatives à la marque pour placer le bouton de connexion.

N'utilisez que des domaines que vous possédez

La procédure de validation de l'écran de consentement 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. Examinez la liste des domaines utilisés par votre application, résumée dans la section Domaines autorisés de l'éditeur de l'écran de consentement OAuth, et identifiez les domaines qui ne vous appartiennent 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 de console d'API en tant que propriétaire ou éditeur.

Si votre projet utilise un fournisseur de services avec un domaine partagé commun, nous vous recommandons d'activer les configurations qui permettraient d'utiliser 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 qui utilise 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 les fonctionnalités qu'elle propose. Les utilisateurs existants peuvent consulter leur liste d'autorisations existantes et accéder à 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é dont vous êtes propriétaire.

Utiliser des URI de redirection et des origines JavaScript sécurisés

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 brut. Google peut rejeter les requêtes OAuth qui ne proviennent pas d'un contexte sécurisé ou qui ne sont pas résolues dans un contexte sécurisé.

Déterminez quelles applications et quels scripts tiers peuvent avoir accès aux jetons et autres identifiants utilisateur qui sont renvoyés à votre page. Limitez l'accès aux données sensibles avec des emplacements d'URI de redirection qui se limitent à 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 de cette page, consultez Envoyer pour validation de la marque pour en savoir plus sur la procédure de validation.