J’utilise plusieurs instances n8n (dev / rec / prod) et j’utilise les identifiants Microsoft Entra ID pour interroger Microsoft Graph (lister les chats par userId, les membres des chats, etc.).
Quand je déploie un workflow de n8n-dev vers n8n-rec, le workflow échoue systématiquement lors de la première exécution planifiée avec : « refreshToken is required » / ERR_ASSERTION.
Le seul moyen de récupérer est d’ouvrir manuellement les identifiants et de cliquer sur « Reconnect » sur l’instance cible. Après quelques heures ou le prochain déploiement, le problème revient.
Je soupçonne qu’il s’agit de la combinaison de trois comportements connus, mais j’aimerais une confirmation de la part de l’équipe n8n et des conseils de bonnes pratiques pour une configuration multi-environnement.
Ce que je pense qu’il se passe
-
Les identifiants ne sont pas transférés avec les exportations de workflow. Le JSON du workflow contient uniquement une référence aux identifiants (id + nom), pas le blob de token chiffré. C’est le comportement attendu.
-
Source Control & Environments exclut explicitement les identifiants. Selon la documentation officielle ( External secrets | n8n Docs ) : « La fonction ne supporte pas l’utilisation d’identifiants différents sur différentes instances. »
-
Microsoft Entra utilise la rotation des refresh tokens. Chaque appel de rafraîchissement invalide le refresh_token précédent et en émet un nouveau. Donc si le même enregistrement d’identifiants existe sur deux instances (dev + rec), l’instance qui se rafraîchit en premier détruit le token de l’autre, ce qui provoque « refreshToken is required » sur la deuxième. C’est documenté dans le problème #26453 ( Microsoft Outlook OAuth2 token refresh fails after ~1 hour on n8n Cloud, masked by dummy.stack.replace error · Issue #26453 · n8n-io/n8n · GitHub ) : « Microsoft Entra ID remplace les refresh tokens par un token frais à chaque utilisation. Si n8n n’enregistre pas le nouveau refresh token, les tentatives de rafraîchissement ultérieures peuvent échouer. » C’est aussi reproduit sur le nœud Entra ID spécifiquement dans le fil communautaire #193787 ( Entra ID node reconnection issues ) et le problème #14426 (Microsoft Entra Component auth failure. · Issue #14426 · n8n-io/n8n · GitHub).
Le nœud est un nœud HTTP Request pointant vers https://graph.microsoft.com/v1.0/users/{id}/chats avec un type d’identifiants prédéfini Microsoft Entra ID (Azure Active Directory) API.
Workflow
ENTRÉE DU WORKFLOW → LISTER CHATS PAR USERID (HTTP Request, Graph API, échoue ici) → DIVISER LA LISTE → BOUCLE SUR LES CHATS → FILTRER CHAT PAR SUJET → si vrai : OBTENIR LES MEMBRES DU CHAT → INFOS UTILISATEURS / si faux : NOM DE CHAT HORS SUJET → FIN DE LA BOUCLE.
Bienvenue @Rodolphe24 dans notre communauté ! Je suis Jay et je suis un créateur certifié n8n.
Votre analyse des causes profondes est exactement juste. Microsoft Entra ID utilise la rotation des jetons de rafraîchissement, donc l’environnement qui appelle en premier le point de terminaison des jetons invalide le jeton de l’autre. La solution est de traiter chaque environnement comme une application OAuth complètement distincte - créez une inscription d’application distincte dans Azure pour le dev et une autre pour la rec, chacune avec son propre ID client/Secret et son propre URI de redirection pointant vers l’instance n8n de cet environnement. Ne partagez jamais le même enregistrement d’identifiants entre instances. Une fois que vous avez configuré cela, chaque environnement gère son propre cycle de rafraîchissement indépendamment et l’invalidation des jetons s’arrête.
bonjour @Rodolphe24
je déconseille aussi de promouvoir des workflows en espérant que la credential ira avec. Ce que j’ai l’habitude de faire dans ces scénarios, c’est de conserver le même nom logique de la credential en dev/rec/prod, mais de reconnecter/créer la credential localement dans chaque instance, en utilisant l’App Registration de cet environnement. De cette façon, le workflow reste facile à promouvoir via le contrôle de source, mais chaque environnement maintient son propre état OAuth et son propre cycle de refresh token. Cela vaut aussi la peine de vérifier si le workflow importé pointe vers la bonne credential dans l’environnement de destination après le pull/deploy.
Merci pour l’input — c’est en fait le modèle que j’utilise déjà :
-
Même nom de credential logique sur dev/rec/prod
-
Inscription Azure App Registration séparée par environnement
-
Chaque credential reconnectée localement sur sa propre instance
Après le déploiement, le workflow pointe vers la bonne credential sur la cible. Avant de publier le workflow, je l’ai déjà lancé avec succès. C’est pour ça que je ne comprends pas…
@Rodolphe24
J’enquêterais sur deux choses : si les credentials reçoivent vraiment un refresh token au moment de la reconnexion, en particulier avec offline_access/admin consent corrects, et si tous les containers/workers de la même instance utilisent la même N8N_ENCRYPTION_KEY.
Bonjour, merci pour vos commentaires. Pourrait-ce être lié à un problème avec un worker n8n ? Quand j’exécute le workflow manuellement, il fonctionne correctement. Cependant, quand je déclenche le workflow principal en utilisant un nœud scheduler après sa publication, je rencontre une erreur de refresh token.
Oui, c’est presque certainement un problème de worker. Lorsqu’un workflow planifié s’exécute via un worker, le worker a besoin de la même clé N8N_ENCRYPTION_KEY que l’instance principale pour déchiffrer les identifiants stockés. S’ils diffèrent, le déchiffrement du jeton échoue et vous obtenez une erreur de refresh token. Vérifiez les variables d’environnement de votre worker et confirmez que N8N_ENCRYPTION_KEY correspond à l’instance principale. Assurez-vous également que le worker a accès à la même base de données où les identifiants sont stockés - un worker connecté à une base de données différente ne verra pas du tout le jeton.
Observation concernant l’erreur refreshToken
J’ai effectué plusieurs tests relatifs à l’erreur refreshToken is required :
-
Test 1 :
Sur l’instance n8n-rec avec des permissions en lecture seule, le lancement du workflow échoue avec l’erreur suivante :
refreshToken is required
-
Test 2 :
Sur l’instance n8n-rec avec des permissions en lecture/écriture, le lancement du workflow produit la même erreur :
refreshToken is required
-
Test 3 :
Après avoir reconnecté manuellement Microsoft Entra ID sur l’instance n8n-rec avec des permissions en lecture/écriture, le workflow se lance avec succès sans aucune erreur.
L’erreur ne s’affiche jamais sur l’instance n8n-dev avec des permissions en lecture/écriture, workflows publiés.
@Rodolphe24 Excellente décomposition du test. Votre résultat du Test 3 a du sens — quand vous reconnectez manuellement la credential sur n8n-rec, Microsoft émet un nouveau token OAuth qui inclut le scope offline_access (nécessaire pour le refresh token). La credential originale stockée dans n8n-rec avait probablement un token expiré ou limité en scope depuis sa configuration initiale.
Le point clé : si la reconnexion sur n8n-rec avec read/write fonctionne, la credential originale n’avait pas le scope offline_access. Pour éviter que cela se reproduise, assurez-vous que votre Azure App Registration a ce scope activé et réautorisez sur chaque instance séparément.
- Créez une inscription d’application distincte dans Azure : une pour Dev, une pour Rec, une pour Prod.
- Injectez votre configuration client dans vos différentes instances de serveur n8n en utilisant des variables d’environnement standard :
MICROSOFT_CLIENT_IDMICROSOFT_CLIENT_SECRETMICROSOFT_TENANT_ID
- Dans votre nœud HTTP Request, changez le type d’authentification en Generic Credential Type → OAuth2.
- Dans les champs de configuration des identifiants, utilisez des expressions n8n pour référencer vos variables d’environnement :
- Client ID :
{{$env.MICROSOFT_CLIENT_ID}}
- Client Secret :
{{$env.MICROSOFT_CLIENT_SECRET}}
Com me n8n évalue les variables d’environnement nativement par instance, votre JSON de workflow reste identique sur Dev, Rec et Prod, mais chaque instance communique avec son propre conteneur Azure isolé.
Faites-moi savoir si cela fonctionne pour vous, sinon, j’ai une autre solution.
Ok, merci pour ton retour, je vais tester ça.
Bonjour, merci pour votre retour, ce n’est pas possible car je dois utiliser l’authentification spécifique basée sur Microsoft Graph : l’API Microsoft Entra ID (Azure Active Directory) qui est également basée sur OAuth2
Ravi que ma réponse ait été utile et sélectionnée comme solution – ça m’a vraiment fait plaisir !
Si tu as d’autres questions sur ce sujet (ou sur d’autres configurations n8n), n’hésite pas à me faire signe, je serai ravi de creuser davantage.
@Rodolphe24
Après le déploiement, avant de cliquer sur « Reconnect », les identifiants REC contiennent-ils toujours un état OAuth valide et s’agit-il des mêmes identifiants utilisés par l’exécution planifiée ?
Si possible, veuillez partager la méthode de déploiement, l’architecture du REC (instance unique ou mode file d’attente/workers/conteneurs multiples), la preuve avant la reconnexion, le journal complet de la première exécution planifiée après le déploiement.
Salut à tous,
Désolé pour la réponse tardive, j’ai été pas mal occupé dernièrement.
Juste pour clore ce sujet : après avoir mis à jour n8n à travers plusieurs versions plus récentes, le problème de jeton d’actualisation que nous rencontrions lors du transfert de flux de travail de notre environnement n8n-dev vers n8n-rec semble avoir disparu.
Nous avons été incapables de reproduire le problème depuis les mises à jour, donc il semble que ce problème ait pu être corrigé dans l’une des versions plus récentes.
Merci à tous pour votre aide et vos perspectives tout au long de cette discussion.
Cordialement
