Pourquoi Google refuse l'OAuth dans une WebView : que faire
Google bloque la connexion dans les navigateurs embarqués. Les raisons, l'erreur disallowed_useragent et la bonne solution : Custom Tabs et PKCE.
Par Kra Ange Fabien Jephté (kra Axiom) · Publié le 24 septembre 2026 · 2 min de lecture
Vous ajoutez « Se connecter avec Google » à votre PWA, tout fonctionne dans Chrome, puis vous l'emballez dans une application : le bouton affiche une erreur 403: disallowed_useragent. Ce n'est pas un bug : c'est une politique.
Pourquoi c'est refusé
Une WebView est un navigateur contrôlé par l'application qui l'embarque. Cette application peut lire les champs de saisie, injecter du JavaScript et intercepter les cookies. Si une connexion Google se déroule dans cette WebView, l'application peut donc voir le mot de passe de l'utilisateur. Google interdit donc les flux OAuth dans les agents utilisateurs embarqués et exige un navigateur « sûr », où l'application ne peut pas espionner la page.
La bonne solution
Ouvrir l'authentification dans le navigateur système :
- Android : Chrome Custom Tabs, un onglet du navigateur présenté dans l'application.
- iOS :
ASWebAuthenticationSession.
Puis revenir dans l'application avec le résultat :
- L'application ouvre l'URL d'autorisation dans l'onglet sécurisé.
- L'utilisateur se connecte chez Google, à l'abri de l'application.
- Google redirige vers une adresse de retour : un lien d'application (App Link / Universal Link) ou un schéma personnalisé.
- L'application reçoit le code et l'échange contre un jeton.
Utilisez PKCE
Pour une application, le secret client ne peut pas rester confidentiel. Le flux Authorization Code avec PKCE protège l'échange : l'application génère un secret à usage unique (code_verifier), en envoie l'empreinte au départ (code_challenge) et le prouve à l'échange. Un code volé ne sert à rien sans ce secret.
Ce qui est possible aujourd'hui avec PWA2APP
Dans une application générée en mode REMOTE, seules les origines que vous autorisez restent dans la WebView : tout autre lien https est ouvert hors de l'application, dans un Custom Tab par défaut. Un bouton de connexion qui redirige vers Google sort donc de la WebView.
Ce qui n'existe pas encore : une méthode du Bridge dédiée pour lancer une session d'authentification et récupérer le retour. Elle n'est pas dans la version actuelle du Bridge (voir la feuille de route). En attendant, gérez le retour par un lien d'application vers votre domaine.
Alternatives à envisager
- Une connexion par e-mail avec lien magique ou code.
- Les clés d'accès (passkeys), qui évitent le mot de passe.
- Un fournisseur qui autorise les flux embarqués, en connaissant les risques.
À retenir
- Ne connectez jamais un utilisateur via Google dans une WebView.
- Utilisez un Custom Tab et le flux Authorization Code avec PKCE.
- Prévoyez le retour dans l'application par un lien vers votre domaine.
