Dans ce guide, nous vous expliquerons comment résoudre le problème, vous ne pouvez pas vous connecter à cette application car elle n’est pas conforme à la politique OAuth 2.0 de Google. Donc, si vous surfez sur Internet depuis des heures pour surmonter la situation, vous pouvez compter sur ce blog. Alors sans plus tarder, commençons. Mais avant cela, discutons de la politique OAuth 2.0 de Google.
Qu’est-ce qu’OAuth ?
Le protocole OAuth (Open Authorization) a été développé par l’Internet Engineering Task Force et permet un accès délégué sécurisé. Il permet à une application d’accéder à une ressource contrôlée par quelqu’un d’autre (utilisateur final). Ce type d’accès nécessite des jetons, qui représentent un droit d’accès délégué. C’est pourquoi les applications obtiennent l’accès sans se faire passer pour l’utilisateur qui contrôle la ressource.
Ici, dans ce blog, nous avons essayé de fournir quelques étapes pour se conformer aux politiques OAuth 2.0 de Google. Afin que vous puissiez suivre les directives pour vous conformer aux problèmes de développement les plus courants rencontrés lors de la préparation de votre application pour la production. Cela vous aidera à atteindre le public le plus large possible avec des erreurs limitées.
Utiliser des projets distincts pour les tests et la production
Les règles Google OAuth nécessitent des projets distincts pour les tests et la production. Certaines politiques et exigences ne s’appliquent qu’aux applications de production. Vous devrez donc peut-être créer et configurer un projet distinct incluant des clients OAuth correspondant à la version de production de votre application disponible pour tous les comptes Google.
Les clients Google OAuth sont utilisés en production et aident à fournir un environnement de collecte et de stockage de données prévisible, plus stable et sécurisé que les mêmes clients OAuth qui testent ou déboguent la même application. Votre projet de production peut être soumis à la vérification et donc être soumis à des exigences supplémentaires pour des portées d’API spécifiques, qui incluent probablement des évaluations de sécurité tierces.
Étape 1 : Accédez à Google API Console, appuyez sur Créer un projet, saisissez un nom et appuyez sur Créer.
Étape 2 : Passez ensuite en revue les clients OAuth sous le projet qui peuvent être liés à votre niveau de test. Le cas échéant, créez des clients OAuth similaires pour les clients de production dans le projet de production.
Étape 3 : Activez ensuite toutes les API utilisées par vos clients
Étape 4 : Après cela, vérifiez la configuration de votre écran de consentement OAuth dans le cadre du nouveau projet.
Les clients Google OAuth utilisés en production ne doivent pas avoir d’environnements de test, d’URI de redirection ou d’origines Java Script disponibles uniquement pour vous ou votre équipe de développement. Nous avons répertorié quelques exemples :
- Les serveurs de test des développeurs individuels
- Versions de test ou de pré-version de l’application
Maintenir une liste de contacts pertinents pour le projet
Google et les API individuelles que vous avez activées peuvent avoir besoin de vous contacter au sujet des modifications apportées à ses services ou des nouvelles configurations requises pour le projet et ses clients. Passez maintenant en revue les listes IAM du projet pour vous assurer que les personnes importantes de votre équipe ont accès pour modifier ou afficher la configuration de votre projet. Notez que ces comptes peuvent également recevoir des e-mails concernant les modifications requises pour le projet.
Le rôle consiste en un ensemble d’autorisations qui permettent à l’utilisateur d’effectuer des actions particulières sur les ressources du projet. Les éditeurs de projet ont l’autorisation d’effectuer les actions qui modifient l’état, comme la possibilité de modifier l’écran de consentement OAuth du projet. Les propriétaires de projet qui disposent de toutes les autorisations d’éditeur peuvent ajouter ou supprimer des comptes lié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 de projet peuvent configurer des informations de facturation pour un projet qui utilise des API payantes.
Les porteurs de projet et les éditeurs doivent être tenus informés. Vous pouvez ajouter plusieurs comptes associés au projet pour vous aider. Assurez-vous d’avoir un accès continu au projet et à la maintenance associée. Les e-mails sont reçus par les comptes qui ont des notifications sur le projet ou des mises à jour de nos services. Les administrateurs de Google Cloud Organization doivent s’assurer qu’un contact accessible est associé à chaque projet de l’organisation. Et s’il n’y a pas d’informations de contact à jour pour votre projet, il y a de fortes chances que vous manquiez des messages obligatoires qui exigent votre action.
Avertissement : Si vous ne répondez pas aux notifications opportunes concernant le projet, vous risquez de perdre l’accès aux API Google.
Points à retenir : l’un des contacts pertinents pour le projet est l’e-mail d’assistance utilisateur configuré pour l’écran de consentement OAuth. Et si les utilisateurs ont des problèmes avec votre application, ou si les administrateurs de Google Cloud Organization ont des questions au nom de leurs utilisateurs, et cette adresse e-mail est affichée afin qu’ils puissent entrer en contact.
Représentez avec précision votre identité
Vous devez fournir un nom d’application authentique, éventuellement un logo à montrer aux utilisateurs. Ces informations sur la marque peuvent représenter exactement l’identité de l’application. Les informations de marque de l’application sont configurées à partir de la page d’écran de consentement OAuth.
Et pour les applications de production, les informations de marque définies dans l’écran de consentement OAuth doivent être confirmées avant d’être affichées aux utilisateurs. Les utilisateurs peuvent être plus enclins à accorder l’accès à l’application une fois la vérification de la marque terminée. Les informations de base sur l’application, qui incluent le nom de l’application, la page d’accueil, les conditions d’utilisation et la politique de confidentialité, sont présentées aux utilisateurs sur l’écran des subventions et lorsqu’ils examinent leurs subventions 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 au service API Google et aux autres produits et services Google pour les applications qui falsifient leur identité ou tentent d’induire les utilisateurs en erreur.
Demander uniquement les étendues que vous souhaitez
Au cours du développement de votre application, vous avez peut-être utilisé un exemple de portée offert par l’API pour faire une preuve de concept au sein de votre application afin d’en savoir plus sur les caractéristiques et les fonctionnalités des API. Ces exemples de champs d’application demandent souvent plus d’informations que la mise en œuvre finale de l’application n’en a besoin, car ils offrent une large couverture de toutes les actions possibles pour une API spécifique.
Par exemple : l’étendue de l’exemple peut demander des autorisations de lecture, d’écriture et de suppression alors que votre application n’a besoin que d’autorisations de lecture, Demander des autorisations pertinentes qui sont limitées aux informations critiques essentielles à la mise en œuvre de l’application.
Passez maintenant en revue la documentation de référence pour le point de terminaison d’API que votre application appelle et notez les portées dont ils ont besoin pour accéder aux données associées dont notre application a besoin. Passez ensuite en revue tous les guides d’autorisation proposés par l’API et décrit les étendues plus en détail afin d’inclure l’utilisation la plus courante. Sélectionnez l’accès aux données le plus minimal dont votre application a besoin pour alimenter les fonctionnalités associées.
Soumettre les applications de production qui utilisent des champs d’application sensibles ou limités pour vérification
Eh bien, certaines étendues sont classées comme “sensibles” ou “restreintes” et ne peuvent pas être utilisées dans les applications de production sans examen. Vous devez saisir toutes les étendues utilisées par votre application de production dans sa configuration d’écran de consentement OAuth. Notez que si votre application de production utilise des étendues sensibles ou limitées, vous devez soumettre votre utilisation d’étendues pour la vérification avant d’inclure des étendues dans une demande d’autorisation.
Utilisez uniquement les domaines que vous possédez
Le processus de vérification de l’écran de consentement OAuth de Google nécessite la vérification de tous les domaines liés à la page d’accueil du projet, à la politique de confidentialité, aux conditions d’utilisation, aux URI de redirection autorisés ou aux origines de script Java autorisées. Passez ensuite en revue la liste des domaines utilisés par votre application et résumés dans la section Domaines autorisés de l’éditeur d’écran de consentement OAuth, puis reconnaissez tout domaine que vous ne possédez pas et que vous ne pourriez donc pas vérifier. Afin de vérifier la propriété des domaines autorisés du projet, utilisez la console de recherche Google. Après cela, utilisez le compte Google associé au projet de console d’API en tant que propriétaire ou éditeur.
Et si votre projet utilise un fournisseur de services avec un domaine partagé standard, nous vous recommandons d’activer les configurations qui peuvent autoriser l’utilisation de votre propre domaine. Certains fournisseurs proposent de mapper leurs services au sous-domaine d’un domaine que vous possédez déjà.
Utiliser des URI de redirection sécurisées et des origines JavaScript
Les clients OAuth 2.0 pour les pages Web doivent sécuriser leurs données qui utilisent des URI de redirection HTTPS et des origines JavaScript, et non HTTP simple. Google peut rejeter les requêtes OAuth qui ne sont pas initiées à partir d’un contenu sécurisé ou qui ne se résolvent pas vers un contenu sécurisé.
Considérez maintenant lesquels des applications et scripts tiers pourraient avoir accès aux jetons et aux autres informations d’identification de l’utilisateur qui renvoient à cette page. Désormais, limiter l’accès aux données sensibles redirigera les emplacements URI limités à la vérification et au stockage des données de jeton.
Prochaines étapes
Une fois que vous êtes assuré que votre application est compilée avec les politiques OAuth 2.0 sur la page, consultez Soumettre pour vérification de la marque pour plus de détails sur le processus de vérification.
Conclusion
C’est tout ce que vous ne pouvez pas vous connecter à cette application car elle n’est pas conforme à la politique OAuth 2.0 de Google. J’espère que vous avez aimé le blog. Merci d’avoir lu.