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 la 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. 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. Cela vous permet de toucher le plus grand public 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 qui inclut 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 contribuent à fournir un environnement de collecte des données et de stockage 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 être soumis à des exigences supplémentaires pour des niveaux d'accès 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 peuvent ê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 votre écran d'autorisation OAuth pour le nouveau projet sur la page Branding de la Cloud Console.

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 des développeurs individuels
  • Les versions de test ou préliminaires de votre application

Tenir une liste des contacts pertinents pour le projet

Google et les API individuelles que vous activez devront peut-être vous contacter au sujet des modifications apportées à ses services ou des nouvelles configurations requises pour votre projet et ses clients. Consultez les listes IAM de votre projet pour vous assurer que les personnes concernées de votre équipe ont accès à la modification ou à l'affichage de 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 d'autorisations pour les actions qui modifient l'état, telles que la possibilité d'apporter des modifications à l'écran de consentement OAuth de votre projet. Les propriétaires de projet qui disposent 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 un contexte expliquant pourquoi les informations de facturation peuvent être définies. Les propriétaires de projet peuvent configurer les informations de facturation pour 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 vous assurer d'avoir un accès continu au projet et à la maintenance associée. Nous envoyons des e-mails à ces comptes lorsqu'il existe des notifications concernant votre projet ou des mises à jour de 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 d'informations de contact à jour pour votre projet, vous risquez de manquer des messages importants qui nécessitent une action de votre part.

Présenter votre identité de manière exacte

Fournissez un nom d'application valide et, si vous le souhaitez, un logo à afficher aux utilisateurs. Ces informations sur la marque doivent représenter avec précision l'identité de votre application. Les informations sur la marque de l'application sont configurées à partir de la page Branding OAuth Branding 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 affichées aux utilisateurs. Les utilisateurs seront peut-être 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 affiché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 services d'API Google et à d'autres produits et services Google pour les applications qui présentent leur identité de manière inexacte ou tentent de tromper les utilisateurs.

Ne demander 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 niveau d'accès fourni par l'API pour créer une preuve de concept dans votre application afin d'en savoir plus sur les fonctionnalités de l'API. Ces exemples de niveaux d'accès demandent souvent plus d'informations que l'implémentation finale de votre application, car ils couvrent de manière exhaustive toutes les actions possibles pour une API particulière. Par exemple, l'exemple de niveau d'accès peut demander des autorisations de lecture, d'écriture et de suppression, tandis 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 pour les points de terminaison d'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 tous les guides d'autorisation proposés par l'API et décrivez leurs niveaux d'accès 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 Ne demander que les niveaux d'accès 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 des services d'API Google.

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

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

Nous vous recommandons vivement de respecter les consignes officielles de branding pour placer le bouton "Se connecter".

N'utiliser que les domaines que vous possédez

Le processus 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. Consultez 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 que vous ne possédez pas et que vous ne pourrez 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 API 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 qui vous 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 la liste des autorisations 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 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 HTTP simple. Google peut refuser les requêtes OAuth qui ne proviennent pas d'un contexte sécurisé ou ne sont pas résolues dans un tel contexte.

Déterminez quelles applications et quels scripts tiers peuvent avoir accès aux jetons et autres identifiants utilisateur qui reviennent sur 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

Une fois que vous vous êtes assuré que votre application est conforme aux règles OAuth 2.0 sur cette page, consultez Envoyer pour validation de la marque pour en savoir plus sur le processus de validation.