LinkedIn
Instagram
WhatsApp
Telegram
Gmail
Outlook
Google Agenda
Rejoindre la communauté SlackÉcran de consentement Google OAuth : Installation, Corrections Et pourquoi il n'apparaît pas (2026)
L'écran de consentement Google OAuth a déménagé en 2024. Il se trouve maintenant dans Plateforme d'authentification Google dans la console Cloud - pas là où vous aviez l'habitude de le trouver. Ce guide vous montre exactement où aller, comment le configurer étape par étape, et comment résoudre les problèmes les plus courants (y compris lorsqu'il refuse de s'afficher).
Où est-il ? Depuis 2024, l'écran de consentement Google OAuth est situé sous APIs & Services > Plateforme d'authentification Google dans la Cloud Console - pas l'ancien élément de menu "Écran de consentement OAuth". Les paramètres sont maintenant divisés en trois onglets : Image de marque (nom de l'application, logo, noms de domaine), Public (Type d'utilisateur interne/externe, utilisateurs de test), et Clients (IDs client OAuth). Si le menu n'apparaît pas du tout, votre projet n'a pas encore activé d'API compatible OAuth, ou votre compte ne dispose pas du rôle Propriétaire ou Éditeur.
Où se trouve l'écran de consentement OAuth en 2026 ?
Si vous avez suivi un tutoriel écrit avant 2024 et que vous ne trouvez pas "Écran de consentement OAuth" dans la barre latérale gauche, vous n'hallucinez pas. Google a renommé et restructuré l'intégralité de la section. Il vit désormais sous un nouveau nom : Plateforme d'authentification Google. C'est la raison la plus courante pour laquelle les développeurs signalent que l'écran de consentement Google OAuth est "absent" - il est toujours là, juste à un autre endroit.
Étape 1 : Aller à console.cloud.google.com et assurez-vous d'avoir sélectionné le bon projet dans le sélecteur de projets en haut. De nombreux problèmes de "non-affichage" sont simplement causés par le fait d'être dans le mauvais projet.
Étape 2 : Dans la barre latérale gauche, cliquez sur API et services.
Étape 3 : Chercher Plateforme d'authentification Google dans le sous-menu (précédemment appelé "Écran de consentement OAuth"). Si vous le voyez, cliquez dessus. Si vous ne le voyez pas, consultez la section de dépannage ci-dessous.
Étape 4 : Vous accéderez au tableau de bord de la plateforme d'authentification Google. Les trois onglets - Image de marque, Public, ou encore Clients - remplacer l'ancien formulaire de consentement sur une seule page.
L'onglet " Audience " dans Google Auth Platform (anciennement « Écran de consentement OAuth ») : c'est là que vous sélectionnez le type d'utilisateur (interne ou externe) et que vous gérez les utilisateurs de test.
Écran de consentement OAuth qui ne s'affiche pas ou qui redirige en permanence : comment le résoudre
L'écran de consentement Google OAuth peut échouer à apparaître ou se comporter de manière inattendue pour plusieurs raisons distinctes. Ci-dessous se trouvent chaque schéma d'erreur avec sa cause exacte et la correction - formaté pour être aussi rapide à scanner que possible.
L'interface utilisateur de la console Google Cloud a changé en 2024. L'ancien élément de menu "Écran de consentement OAuth" a été renommé en "Plateforme d'authentification Google". Les anciens tutoriels font toujours référence à l'ancien nom.
Dans la barre latérale gauche, sous API et services, faites défiler jusqu'à ce que vous voyiez "Plateforme d'authentification Google". Si vous ne le voyez toujours pas, vous devrez peut-être d'abord activer au moins une API Google sur votre projet (la section n'apparaît qu'une fois qu'une API compatible OAuth est.
Votre compte Google ne dispose pas de Rôle IAM de propriétaire ou d'éditeur sur le projet. Les comptes avec le rôle de spectateur ne peuvent pas modifier les paramètres de l'écran de consentement.
Demandez au responsable du projet de vous accorder le Éditeur rôle (ou supérieur) via IAM et Admin > IAM. Si vous avez créé le projet vous-même, vérifiez que vous êtes connecté avec le bon compte Google : il arrive parfois que la liste des projets affiche des projets auxquels vous n'avez qu'un accès en lecture seule.
Vous n'avez rien sélectionné type d'utilisateur (Interne ou externe) pour l'instant. Dans la nouvelle interface utilisateur, le bouton " Commencer " de la page de présentation de la plateforme d'authentification Google vous invite à effectuer d'abord l'étape « Audience ».
Sur la page de présentation de la plate-forme d'authentification Google, cliquez sur "Démarrer" si demandé, alors naviguer vers le Onglet Audience et choisissez soit "Interne" soit "Externe". Une fois le type d'utilisateur enregistré, le formulaire de configuration complet de la marque devient disponible.
Votre application se trouve dans État des tests (ou le statut de publication est ".
Pour le développement : ajoutez l'e-mail de l'utilisateur de test à votre liste des utilisateurs de test (Onglet Audience). Pour la production : soumettez votre application pour la vérification OAuth de Google. Les utilisateurs répertoriés comme utilisateurs de test verront toujours un avertissement, mais pourront continuer en cliquant sur "Avancé > Accéder à [Nom de l'application]". L'avertissement disparaît une fois votre application vérifiée et publiée.
Il s'agit d'un comportement normal. Une fois que l'utilisateur a donné son consentement, Google en garde la trace et ignore cet écran lors des connexions suivantes. L'écran de consentement ne s'affiche à nouveau que si l'utilisateur révoque l'accès ou si vous demandez de nouveaux champs d'application.
Pour forcer le réaffichage pour les tests, ajoutez consentement à vos paramètres d'URL d'autorisation. En production, utilisez uniquement consentement lors du premier appel d'autorisation (pour recevoir le token_rafraîchissement) - pas à chaque connexion.
accès_refusé erreur à la place. Les applications internes sont limitées aux utilisateurs de votre organisation Google Workspace par conception. Passez à Externe si vous avez besoin de prendre en charge les utilisateurs non-Workspace.La clé OAuth pré-vérifiée d'Unipile élimine ces scénarios d'erreur de votre configuration - aucune configuration d'écran de consentement de votre côté, en tant qu'intermédiaire technique indépendant agissant au nom de chaque utilisateur authentifié.
Comment configurer l'écran de consentement OAuth étape par étape
Cette section couvre la configuration complète de l'écran de consentement : la partie que vous devez compléter après avoir créé un projet Google Cloud et activé une API Google. Si vous n'avez pas encore effectué ces étapes, consultez le Guide complet d'authentification Google OAuth qui couvre d'abord la création de projet et l'activation d'API.
Dans le Onglet Audience, la première décision est de savoir si votre application s'adresse aux utilisateurs au sein de votre organisation Google Workspace ou à tout titulaire de compte Google :
- Interne : uniquement les utilisateurs de votre organisation Google Workspace. Aucune vérification requise. Idéal pour les outils internes, les panneaux d'administration ou les applications d'entreprise utilisées uniquement par vos propres employés. Non disponible si votre projet est rattaché à un compte Gmail personnel (comptes Workspace uniquement).
- Extérieur tout détenteur d'un compte Google. Les applications démarrent en mode "Test" avec une limite de 100 utilisateurs. Les champs d'application sensibles ou restreints nécessitent le processus de vérification de Google avant que l'application ne puisse être publiée auprès de tous les utilisateurs.
Onglet Audience : choisissez Interne (réservé à l'espace de travail) ou Externe (tout compte Google). Cette décision affecte vos exigences de vérification.
Astuce : vous pouvez passer de Interne à Externe plus tard, mais vous ne pouvez pas revenir d'Externe à Interne une fois que les utilisateurs ont autorisé votre application. Choisissez avec soin.
Dans le Onglet Marque, remplissez les champs suivants. Ce sont ceux que les utilisateurs voient sur l'écran de consentement Google OAuth lorsqu'ils autorisent votre application:
- Nom de l'application : le nom affiché de manière proéminente en haut de l'écran de consentement. Utilisez le nom de votre produit, pas un identifiant technique.
- Courriel de support utilisateur : affiché sur l'écran de consentement comme contact pour les utilisateurs ayant des questions sur la demande d'accès de votre application. Utilisez un alias surveillé ou une liste de distribution, pas un e-mail personnel.
- Logo de l'application Un PNG ou JPG carré, minimum 120x120px. Apparaît sur l'écran de consentement et dans la liste des applications autorisées du compte Google. Facultatif mais fortement recommandé pour la confiance de l'utilisateur.
Onglet Image de marque - Informations sur l'application : renseignez le nom de l'application, le logo et l'e-mail de support tels que vous souhaitez qu'ils apparaissent à l'utilisateur sur l'écran de consentement.
Toujours dans le Onglet Marque, la section Domaine de l'application nécessite les liens suivants :
- URL de la page d'accueil de l'application : la page d'accueil publique de votre application ou produit. Doit être une URL en direct et accessible (pas une page de connexion).
- Lien vers la politique de confidentialité : requis pour toutes les applications externes demandant des scopes au-delà de la connexion de base. Doit mentionner explicitement les scopes Google que vous demandez et comment les données sont utilisées. L'équipe de vérification de Google examine cela attentivement - une politique de confidentialité manquante ou vague est la raison la plus courante de rejet.
- Lien vers les conditions d'utilisation : facultatif mais recommandé pour les applications de production.
Domaine d'application : fournissez des URL actives pour votre page d'accueil, votre politique de confidentialité et vos conditions d'utilisation. Toutes les URL doivent être accessibles publiquement avant de soumettre pour vérification.
Le Domaines autorisés (sous Domaine de l'application) contrôle les domaines qui peuvent être utilisés dans vos URI de redirection OAuth et dans les liens du domaine de l'application ci-dessus. Ajoutez le domaine racine de votre application (par exemple,. yourapp.com).
Domaines autorisés : ajoutez votre domaine racine. Seuls les URI de redirection et les URL d'applications de ce domaine seront acceptés par Google.
Astuce : Les domaines autorisés et les URI de redirection (définis dans l'onglet Clients) doivent être cohérents. Si votre URI de redirection est https://app.yourapp.com/callback, vous devez autoriser yourapp.com ici, pas app.yourapp.com.
Aussi dans le Onglet Marque, fournir une adresse e-mail de contact du développeur. C'est l'adresse que Google utilise pour envoyer :
- Mises à jour du statut de vérification (approbation, rejet ou demande de clarification)
- Avis de conformité aux politiques
- Notifications concernant les changements du statut OAuth de votre application
Contact développeur : utiliser une liste de distribution surveillée. Les e-mails critiques de vérification Google peuvent être filtrés comme spam – vérifiez le dossier spam pendant votre fenêtre de révision.
Important : Utilisez une liste de distribution ou une boîte de réception partagée, pas un e-mail personnel. L'équipe de vérification de Google peut envoyer des e-mails pendant les heures ouvrables dans un fuseau horaire différent. Si vous manquez la fenêtre de réponse, votre vérification peut être retardée de plusieurs semaines.
Les champs d'application définissent les données auxquelles votre application peut accéder pour le compte de l'utilisateur. Dans la nouvelle interface utilisateur de la plateforme d'authentification Google, les Onglet Clients > sélectionner un client > Portées). Cliquer "Ajouter ou supprimer des portées" pour ouvrir le sélecteur de portée.
Catégories de portée qui affectent votre parcours de vérification :
- Scopes non sensibles par exemple.
openid,l'email,profil): connexion de base uniquement. Aucune vérification requise. Publication immédiate de l'application. - Portées sensibles par exemple.
gmail.lecture seule,gmail.envoyer,libellés gmail): nécessite une évaluation de sécurité Google (vérification OAuth). L'application reste en mode Test jusqu'à vérification. - Portées restreintes par exemple.
mail.google.com,gmail.modifierrequire à la fois une vérification Google OAuth ET un audit de sécurité CASA Tier 2. Prend beaucoup plus de temps.
Sélecteur d'étendues : choisissez les étendues minimales dont votre application a réellement besoin. Chaque étendue sensible ou restreinte ajoute des exigences de vérification. Planifiez cela avant de construire.
Pour une référence complète des scopes spécifiques à Gmail, les API que chacun déverrouille et la manière de les demander dans votre URL d'autorisation, consultez Guide des scopes de l'API Gmail.
Principe du moindre privilège : ne demandez que les scopes que votre application utilise actuellement. Ajouter un scope restreint après le lancement implique de redémarrer l'intégralité du processus de vérification, y compris un nouvel audit CASA de niveau 2.
Dans le Onglet Audience, le Test utilisateurs La section vous permet d'ajouter des adresses e-mail du compte Google qui peuvent autoriser votre application pendant qu'elle est en État des tests.
Règles clés concernant le plafond des utilisateurs de test :
- 100 utilisateurs de test maximum peut être ajouté à une application externe en statut de test. Ceci est une limite stricte de Google - vous ne pouvez pas l'augmenter sans publier votre application.
- Les utilisateurs test voient l'écran d'avertissement "application non vérifiée" mais peuvent toujours autoriser votre application en passant outre l'avertissement.
- Les jetons d'accès pour les utilisateurs de test en mode test expirent après 7 jours. Les utilisateurs doivent se ré-autoriser lorsque le jeton expire.
- Une fois que vous soumettez votre application pour vérification et qu'elle est approuvée par Google, le plafond de 100 utilisateurs est levé et l'expiration de 7 jours disparaît.
Si vous avez besoin de plus de 100 utilisateurs avant la vérification : la seule option est de soumettre votre application à la vérification de Google. Il n'y a pas de solution de contournement dans les systèmes de Google. Alternativement, considérez si la clé OAuth pré-vérifiée d'Unipile (section suivante) peut gérer le flux OAuth pour vous, éliminant ainsi à la fois le plafond et le délai de vérification.
Voulez-vous ignorer complètement ce processus d'écran de consentement OAuth ?
Utilisez la clé OAuth vérifiée d'Unipile à la place - pas d'écran de consentement à configurer, pas de limite de 100 utilisateurs, pas d'attente de vérification.
Interne ou externe : lequel devriez-vous choisir ?
Le choix "Interne" ou "Externe" sur l'écran de consentement Google OAuth est l'une des décisions les plus importantes de votre configuration. Il détermine votre parcours de vérification, votre base d'utilisateurs et si vous serez confronté à une limite de 100 utilisateurs pendant le développement. Voici le tableau complet.
Ignorer entièrement
Avec la clé OAuth pré-validée d'Unipile, vous servez des utilisateurs externes sans vérification Google – Unipile agit comme un intermédiaire technique indépendant pour le compte de chaque utilisateur authentifié.
Après l'écran de consentement : vérification et CASA
La finalisation de la configuration de l'écran de consentement Google n'est pas la fin du processus pour les applications externes qui demandent des scopes sensibles ou restreints. Ce qui suit dépend des scopes que vous avez choisis. Voici la version courte - la vérification complète et la visite guidée CASA se trouvent dans Hub Google OAuth.
Juste après avoir configuré l'écran de consentement oauth, votre application externe est en État des tests. Seuls les utilisateurs que vous ajoutez à la liste des utilisateurs de test (jusqu'à 100) peuvent autoriser votre application. C'est parfait pour le développement et les premiers tests.
Lorsque vous êtes prêt(e) à ouvrir votre application à plus d'utilisateurs, cliquez sur "Préparez-vous à la vérification" (ou " Soumettre pour vérification ") dans la présentation de la plate-forme d'authentification Google. Google examine la politique de confidentialité de votre application, les domaines autorisés, les champs d'application demandés et la manière dont votre application utilise les données. Le temps de révision varie : généralement de 2 à 6 semaines, parfois plus longtemps pour les champs d'application restreints.
Si votre application demande des scopes restreints (comme mail.google.com ou gmail.modifier), Google exige également un Audit de sécurité CASA niveau 2 par un évaluateur tiers agréé. Cela implique un examen de la posture de sécurité de votre application, de la gestion des données et des contrôles d'accès.
Une fois vérifiée, votre application est publiée. L'écran d'avertissement "application non vérifiée" disparaît. Le plafond de 100 utilisateurs est levé. L'expiration du jeton de 7 jours pour les utilisateurs de test ne s'applique plus. Les utilisateurs voient votre écran de consentement personnalisé sans avertissements.
Pour une vision plus large de la façon dont Google OAuth s'intègre dans l'architecture des API d'e-mail - y compris l'accès unifié aux fournisseurs pour Gmail, Outlook et IMAP - consultez Guide de l'API e-mail.
Unipile a déjà terminé l'audit CASA de niveau 2 pour son intégration Google OAuth. Cela signifie que lorsque vous utilisez Unipile comme un intermédiaire technique indépendant, agissant au nom de chaque utilisateur authentifié, vous n'avez pas à passer par le processus CASA vous-même. Voir le centre complet Google OAuth pour les détails sur le parcours de certification d'Unipile et le fonctionnement du flux POC / certifier plus tard / basculer.
Ignorer complètement la configuration de l'écran de consentement
Si votre produit doit accéder aux données Gmail ou Google Agenda des utilisateurs, vous pouvez choisir de gérer vous-même la configuration de l'écran de consentement Google OAuth, ou vous pouvez utiliser Unipile en tant qu'intermédiaire technique indépendant, agissant au nom de chaque utilisateur authentifié, avec une clé OAuth pré-vérifiée qui a déjà la certification CASA de niveau 2. Ceci n'est pas une solution de contournement pour la révision de sécurité de Google. Unipile a terminé cet examen pour vous - c'est le produit.
Unipile n'est pas affilié, approuvé ou sponsorisé par Google. Unipile fonctionne comme un intermédiaire technique indépendant entre votre application et l'infrastructure Google OAuth.
Connectez les comptes Google de vos utilisateurs via l'intégration OAuth vérifiée d'Unipile. Vos utilisateurs autorisent une seule fois - Unipile se charge du reste, en tant qu'intermédiaire technique indépendant, pour le compte de chaque utilisateur authentifié.
Écran de consentement Google OAuth - FAQ
Les questions les plus fréquentes sur la configuration, le dépannage et la navigation de l'écran de consentement Google OAuth en 2026.
Il y a cinq raisons courantes : (1) Vous cherchez l'ancien menu "Écran de consentement OAuth" - il a été renommé "Plateforme d'authentification Google" en 2024. (2) Vous êtes dans le mauvais projet - vérifiez le sélecteur de projet en haut. (3) Votre compte ne dispose pas du rôle IAM Propriétaire ou Éditeur. (4) Aucune API compatible OAuth n'a encore été activée pour le projet - la section Plateforme d'authentification Google n'apparaît qu'une fois qu'une API est activée. (5) Votre application est configurée comme Interne, mais vous testez avec un compte Google externe. Les applications internes bloquent tous les utilisateurs non-Workspace par conception. Pour des solutions détaillées, voir la section de dépannage ci-dessus.
Depuis 2024, naviguez vers APIs & Services > Plateforme d'authentification Google. L'ancien élément de menu "Écran de consentement OAuth" n'existe plus - il a été remplacé par Plateforme d'authentification Google, qui organise les paramètres en trois onglets : Image de marque (nom de l'application, logo, noms de domaine), Public (Type d'utilisateur interne/externe, utilisateurs de test), et Clients (Identifiants du client OAuth et URI de redirection). Cette restructuration de l'interface utilisateur est la principale cause de la requête de recherche "l'écran de consentement Google OAuth ne s'affiche pas" en 2026.
Plus d'informations à ce sujet dans notre Guide complet du Google OAuth Playground.Internetous les utilisateurs sont dans votre organisation Google Workspace, aucune vérification jamais requise, pas de limite d'utilisateurs de test, aucun avertissement de non-vérifié. Idéal pour les outils internes. Nécessite un compte Workspace (pas un Gmail personnel).
ExterneTout titulaire de compte Google peut utiliser votre application. Commence en mode test (limité à 100 utilisateurs). Les scopes sensibles nécessitent une vérification Google (2-6 semaines). Les scopes restreints nécessitent en plus le niveau CASA 2. Choisissez Externe pour toute application publique ou destinée aux clients.
Le plafond dur est 100 utilisateurs test pour les applications externes en statut de test. Cette limite est fixée par Google et ne peut être contournée. Les utilisateurs de test peuvent toujours autoriser votre application mais verront d'abord un écran d'avertissement. Leurs jetons expireront après 7 jours (au lieu de la durée de vie normale du jeton de rafraîchissement). Pour lever la limite, soumettez votre application pour la vérification OAuth de Google. Une fois publiée, il n’y a pas de limite d’utilisateurs.
Cela dépend de votre configuration : Applications internes n'a jamais besoin de vérification. Applications externes utilisant uniquement des champs d'application de base (openid, l'email, profil) peut publier sans vérification. Applications externes demandant des champs d'application sensibles comme gmail.envoyer, gmail.lecture seule) doivent passer la vérification OAuth de Google avant de lever le plafond de 100 utilisateurs. Applications externes demandant des autorisations restreintes comme mail.google.com) exigent en outre un audit de sécurité CASA Tier 2 - en plus de la vérification standard. Voir la Guide des scopes de l'API Gmail pour la classification complète.
Vous ne pouvez pas sauter l'écran de consentement Google OAuth au sein de l'infrastructure de Google elle-même ; c'est une étape obligatoire pour tout flux OAuth 2.0. Cependant, vous pouvez éviter de le configurer et de le faire vérifier vous-même en utilisant Clé OAuth pré-authentifiée d'Unipile. Unipile agit en tant qu'intermédiaire technique indépendant, pour le compte de chaque utilisateur authentifié, avec la vérification Google et la certification CASA Tier 2 déjà effectuées. Ce n'est pas une solution de contournement de sécurité - Unipile a passé le processus d'examen complet de Google. Vos utilisateurs voient toujours un écran de consentement (celui vérifié par Unipile), vous n'avez tout simplement pas à créer et vérifier le vôtre.
Découvrir Intégration de l'API Gmail prête pour la production.Vous avez encore des questions sur la configuration de Google OAuth ? Notre équipe est là pour vous aider.
FR 
EN 
ES 
DE 
IT 
BR 
NL 
PL 
TR