Identifiants du nœud Outlook Microsoft OAuth2 - « Approbation administrateur requise »

Bonjour à tous,

J’ai un problème pour connecter les identifiants du nœud Microsoft Outlook dans n8n.

Quand je clique sur « Connecter maintenant », j’obtiens ce message :

« Approbation de l’administrateur requise »

Nous utilisons un compte de licence n8n

Dans Azure, les paramètres de consentement des utilisateurs sont configurés comme suit :

« Ne pas autoriser le consentement de l’utilisateur »
« Un administrateur sera requis pour toutes les applications et identités d’agent. »

Pour cette raison, les utilisateurs ordinaires ne peuvent pas consentir à l’inscription de l’application.

Mon administrateur a déjà approuvé la demande de consentement, mais la connexion dans n8n ne fonctionne toujours pas.

Quelqu’un a-t-il déjà connu ce problème ?
Ai-je besoin de permissions supplémentaires, d’un consentement administrateur pour des étendues d’API spécifiques, ou de paramètres différents pour l’inscription d’application Azure concernant le nœud Outlook/Microsoft ?

Merci !

Le consentement administrateur a-t-il été formellement appliqué au niveau à l’échelle du locataire, @dana_bida ?

@dana_bida le “Need Admin Approval” dans cette configuration se produit parce que ton tenant a le consentement utilisateur désactivé (ce que tu as mentionné), donc le flux OAuth se bloque à l’écran de consentement même pour les scopes à faible risque. en continuant sur la question de @kjooleng, il y a en fait deux niveaux de consentement administrateur à vérifier et les deux doivent être en place :

premier niveau — le consentement administrateur a-t-il été appliqué au niveau du tenant, et pas seulement au compte personnel de l’admin ? quand ton admin clique sur l’approbation, il doit spécifiquement cocher la case “Consent on behalf of your organization” sur l’écran de consentement. sans ça, la permission s’applique à cet admin utilisateur seulement, pas à toute l’org, donc quand les utilisateurs ordinaires essaient de se connecter ils rencontrent le même blocage.

deuxième niveau — l’admin a-t-il accordé TOUS les scopes que le node Outlook de n8n demande ? l’ensemble typique est offline_access, Mail.ReadWrite, Mail.Send, Calendars.ReadWrite, MailboxSettings.Read, et certains de ceux-ci peuvent nécessiter un consentement administrateur explicite par scope selon la config du tenant.

le moyen le plus rapide de forcer le consentement administrateur au niveau du tenant correctement est de frapper directement l’URL de consentement administrateur, admin dans le navigateur :

ton tenant-id est dans Azure portal → Entra ID → Overview. le client_id de l’app n8n et l’URL de callback dépendent de si tu es sur n8n Cloud (utilise la propre app Azure de n8n — id visible dans la modal de credential dans n8n) ou self-hosted (utilise ta propre inscription d’app Azure).

si tu ne peux pas obtenir le consentement au niveau du tenant via ton admin (certaines orgs verrouillent ça vraiment bien pour n’importe quelle app tierce), le chemin plus propre est d’enregistrer ta PROPRE Inscription d’App Azure et de basculer vers le type de credential “Microsoft OAuth2 API” dans n8n avec ClientID/Secret personnalisés. ta propre app, ton tenant l’approuve une fois, et l’admin garde le contrôle total sur les scopes. ça prend environ 10 min dans Azure portal.

es-tu sur n8n Cloud ou self-hosted ? ça change quel client_id tu mettrait dans l’URL de consentement.

Une vérification supplémentaire : une fois que votre administrateur accorde le consentement au niveau du locataire, allez dans Azure Portal → Entra ID → Applications d’entreprise → trouvez l’application n8n → Autorisations, et confirmez qu’elle affiche le statut « Accordé pour [votre organisation] » sur les portées requises. Si certaines portées affichent toujours « Non accordé », c’est le blocage restant - l’administrateur doit accorder le consentement spécifiquement pour ces portées manquantes, pas seulement approuver la demande initiale.


Salut :waving_hand:

Ce problème vient généralement des paramètres de permissions Azure, pas de n8n lui-même. Veuillez vérifier ces points :

  1. Le consentement administrateur est entièrement accordé
    Allez dans Azure → Inscriptions d’applications → Autorisations API
    Assurez-vous que les autorisations requises (Mail.Read, Mail.Send, User.Read, offline_access) sont ajoutées, puis cliquez sur « Accorder le consentement administrateur ».
    Approuver simplement la demande ne suffit pas.

  1. Vérifiez l’application d’entreprise
    Allez dans Entra ID → Applications d’entreprise
    Assurez-vous que :
  • Le consentement s’affiche comme « Accordé »

  • L’application n’est pas bloquée pour les utilisateurs


  1. L’URL de redirection est correcte
    Dans Inscription d’application → Authentification
    Ajoutez exactement cette URL depuis n8n :

https://YOUR-N8N-DOMAIN/rest/oauth2-credential/callback

Même une petite différence peut causer cette erreur.


  1. Reconnectez-vous dans n8n
    Après avoir apporté des modifications :
  • Supprimez les identifiants Outlook dans n8n

  • Créez-les à nouveau

  • Essayez « Se connecter maintenant » à nouveau


  1. Assurez-vous que la bonne application est utilisée
    L’ID client dans n8n doit correspondre à l’inscription d’application Azure.

Dans la plupart des cas, le problème provient soit du consentement administrateur manquant, soit d’une URL de redirection incorrecte :+1:

Consentement administrateur approprié + URI de redirection correct + reconnexion OAuth nouvelle dans n8n

Bonjour,
Merci pour la réponse rapide,
Le problème était que je devais ajouter une autorisation de portée cachée qui existe dans les identifiants intégrés Microsoft Outlook :
openid offline_access Contacts.Read Contacts.ReadWrite Calendars.Read Calendars.Read.Shared Calendars.ReadWrite Mail.ReadWrite Mail.ReadWrite.Shared Mail.Send Mail.Send.Shared MailboxSettings.Read

Il me manquait les identifiants Shared ; cependant, je ne suis pas certain que ces identifiants soient sécurisés pour le partage

Les portées .Shared permettent uniquement au workflow de consulter les éléments qui ont déjà été partagés avec l’utilisateur authentifié via le partage/la délégation normal d’Outlook — pas les e-mails privés ou les calendriers d’autres utilisateurs. Tu ne contournes rien que Microsoft n’ait déjà approuvé. C’est sans risque de laisser activé pour une utilisation standard, ça vaut seulement la peine de désactiver si tu ne veux spécifiquement pas que le workflow voie les boîtes aux lettres partagées que ton utilisateur voit déjà dans Outlook de toute façon.