Redirection OAuth vers localhost : réparer les identifiants Google/Microsoft

Lorsque n8n affiche l'erreur redirect_uri_mismatch lors de la connexion d'un compte Google ou Microsoft, ou que vous atterrissez soudainement sur http://localhost:5678/... après avoir cliqué sur « Sign in », c'est presque toujours parce que n8n construit encore l'adresse de callback pour la connexion OAuth à partir des valeurs par défaut localhost et du port 5678, au lieu de votre véritable domaine public. Google ou Microsoft comparent cette redirect URI envoyée par le serveur n8n avec la liste que vous avez enregistrée dans la Google Cloud Console ou dans l'enregistrement de l'application Microsoft, et refusent la connexion dès que les deux ne correspondent pas exactement. La solution consiste à définir correctement les variables d'environnement N8N_HOST, N8N_PROTOCOL et surtout WEBHOOK_URL ou N8N_EDITOR_BASE_URL sur le domaine public, puis à saisir la redirect URI affichée dans le formulaire d'identifiants n8n telle quelle chez le fournisseur OAuth. En date de : juillet 2026.

Pourquoi n8n construit-il la redirect URI à partir de localhost ?

Par défaut, n8n calcule automatiquement les adresses de l'éditeur et des webhooks à partir de trois variables, et sans configuration propre, selon la documentation n8n sur les variables d'environnement de déploiement ce sont les valeurs par défaut qui s'appliquent : http pour N8N_PROTOCOL, localhost pour N8N_HOST et 5678 pour N8N_PORT. Tant que vous testez n8n uniquement en local sur votre propre ordinateur, ce n'est pas un problème, car le navigateur accède effectivement via localhost. Mais dès que n8n s'exécute sur un serveur, dans Docker ou derrière un reverse proxy, Google ou Microsoft accèdent quand même toujours à la même valeur localhost calculée automatiquement, car n8n ne sait pas de l'extérieur sous quel domaine il est réellement accessible.

Comment configurer correctement N8N_HOST, WEBHOOK_URL et N8N_EDITOR_BASE_URL ?

La solution la plus fiable consiste à définir manuellement WEBHOOK_URL sur le domaine public complet, car cette variable écrase, selon la documentation n8n sur la configuration des webhooks derrière un reverse proxy l'intégralité de l'URL calculée automatiquement, et elle est à la fois affichée dans l'éditeur et enregistrée auprès des services externes.

• WEBHOOK_URL : définir l'adresse publique complète avec une barre oblique finale, par exemple https://n8n.votredomaine.fr/, afin que n8n utilise ce domaine au lieu de localhost.
• N8N_HOST : définir sur le domaine seul sans protocole, par exemple n8n.votredomaine.fr, car n8n utilise cette valeur avec N8N_PROTOCOL et N8N_PORT pour le calcul automatique de l'URL.
• N8N_PROTOCOL : définir sur https dès que votre serveur est accessible via SSL, car la valeur par défaut selon la documentation est http.
• N8N_EDITOR_BASE_URL : l'URL publique sous laquelle les utilisateurs accèdent à l'éditeur ; selon la documentation, elle est également utilisée pour les e-mails envoyés par n8n et comme URL de redirection lors de la connexion SAML.
• N8N_PROXY_HOPS : définir sur 1 si un reverse proxy est placé devant, afin que n8n interprète correctement les en-têtes de transfert.

Après avoir défini ces variables, le processus ou le conteneur n8n doit être redémarré, car n8n ne lit les variables d'environnement qu'au démarrage.

Comment corriger concrètement l'erreur redirect_uri_mismatch ?

L'erreur survient parce que n8n envoie un paramètre redirect_uri à Google ou Microsoft au démarrage du flux OAuth, qui ne correspond pas à la redirect URI enregistrée chez le fournisseur, c'est pourquoi vous devez aligner manuellement les deux côtés. Après le redémarrage de n8n, ouvrez à nouveau l'identifiant concerné et faites-vous afficher l'URL de redirection OAuth actuelle, que n8n construit sous le chemin /rest/oauth2-credential/callback. Copiez cette adresse telle quelle dans la liste des redirect URIs autorisées de votre client OAuth Google ou de votre enregistrement d'application Microsoft, et enregistrez-la là-bas. Pour les connexions Google, la documentation n8n sur les problèmes Google Drive indique explicitement que N8N_EDITOR_BASE_URL et WEBHOOK_URL doivent utiliser des domaines pleinement qualifiés afin d'éviter précisément ce redirect URI mismatch. Reconnectez ensuite l'identifiant dans n8n afin que le token actualisé soit récupéré.

Que faut-il faire de plus lorsque n8n s'exécute derrière un reverse proxy ou dans Docker ?

Si n8n s'exécute conteneurisé derrière nginx, Traefik ou un Cloudflare Tunnel, le simple fait de définir les variables ne suffit parfois pas, car le proxy doit transmettre à n8n les en-têtes d'origine tels que X-Forwarded-Proto et X-Forwarded-Host, afin que le service sache en interne que la requête est effectivement arrivée via https et le domaine public. Vérifiez donc en plus de la configuration du proxy si N8N_PROXY_HOPS est défini, car sans cette valeur, n8n ne fait pas confiance aux en-têtes de transfert du proxy et revient en interne aux valeurs par défaut. Quiconque souhaite exploiter une instance n8n en production avec plusieurs connexions OAuth, sans avoir à reconfigurer les redirect URIs à chaque déménagement de serveur, tire profit d'une configuration proprement documentée ; c'est l'un des points sur lesquels NordFlux lors de la mise en place de n8n apporte son soutien, afin que les automatisations avec souveraineté des données allemande continuent de fonctionner de manière stable même après une mise à jour.

Questions fréquentes sur les problèmes de redirection OAuth dans n8n

Dois-je redémarrer n8n après avoir défini les variables ?

Oui, un redémarrage est impératif, car n8n ne lit les variables d'environnement qu'au démarrage du processus ou du conteneur. Sans redémarrage, l'ancienne redirect URI basée sur localhost reste active, même si WEBHOOK_URL ou N8N_HOST sont déjà correctement définis.

Suffit-il de définir uniquement WEBHOOK_URL ?

Dans la plupart des cas, oui, car selon la documentation n8n, WEBHOOK_URL écrase l'intégralité de l'URL calculée automatiquement et corrige ainsi également l'adresse de callback OAuth. Vous n'avez besoin de N8N_EDITOR_BASE_URL en plus que si les liens dans les e-mails envoyés automatiquement ou les redirections SAML s'affichent encore de façon incorrecte.

Pourquoi redirect_uri_mismatch survient-il parfois aussi avec n8n Cloud ?

L'erreur peut aussi survenir avec n8n Cloud si l'URL de redirection affichée dans la boîte de dialogue des identifiants ne correspond plus exactement à l'adresse enregistrée chez le fournisseur, par exemple après un changement de domaine de workspace. Dans ce cas, il est utile de copier à nouveau la redirect URI actuellement affichée et de la mettre à jour dans la Google Cloud Console ou l'enregistrement d'application Microsoft.

La même solution s'applique-t-elle aussi aux identifiants Microsoft ?

Oui, le principe est identique pour les connexions Microsoft ou Azure, car là aussi une correspondance exacte est requise entre la redirect URI envoyée par n8n et la reply URL enregistrée dans l'enregistrement d'application. Définissez donc les mêmes variables N8N_HOST, N8N_PROTOCOL et WEBHOOK_URL, et saisissez l'adresse affichée dans l'identifiant n8n dans la liste des reply URLs de votre enregistrement d'application Azure.