Teams Node Requires Group.ReadWrite.All Permission – Enterprise Security Concern

Hello ,

while testing the Microsoft Teams node for an enterprise deployment, I noticed that the node appears to require the Microsoft Graph permission Group.ReadWrite.All even for simply sending a message into a Teams channel.

For testing, I already configured the following delegated scopes for the app registration:

  • User.Read

  • Team.ReadBasic.All

  • ChannelMessage.Read.All

  • ChannelMessage.ReadWrite

  • ChannelMessage.Send

  • Subscription.Read.All

  • Chat.Read

Even this already feels overly permissive for such a simple use case from an enterprise security perspective.

However, the Teams node still does not work unless Group.ReadWrite.All is granted.

The returned error is:

Missing scope permissions on the request. API requires one of ‘ChannelMessage.Send, Group.ReadWrite.All’. Scopes on the request ‘ChannelMessage.Read.All, ChannelMessage.ReadWrite, Chat.Read, openid, Subscription.Read.All, Team.ReadBasic.All, User.Read, profile, email’

What is especially concerning is that ChannelMessage.Send is already configured in the app registration, but apparently is not included in the effective token scopes used by the node.

From our testing and review of the Microsoft Graph API documentation, it does not appear that sending a simple channel message should require Group.ReadWrite.All.

At the moment, this looks like either:

  • a bug in the Teams node authentication/scope handling

  • or an unnecessarily broad permission requirement enforced by the node itself

From an enterprise security perspective, this is a serious issue because Group.ReadWrite.All grants extremely broad tenant-wide access and violates least-privilege principles for a simple messaging workflow.

In its current state, this effectively makes the Teams node unusable in many enterprise environments due to security and compliance requirements.

Could you please clarify why this permission is required and whether support for granular permissions such as ChannelMessage.Send is planned?

Thank you.

welcome @Daniel_Stahl

you can use the community node n8n-nodes-msteams-lite instead. It allows you to specify exactly which permissions your workflow needs,removing the need for broad Group.ReadWrite.All access.

I already reviewed the n8n-nodes-msteams-lite community node. However, from an enterprise security and compliance perspective, I am not sure whether relying on external community npm packages is a viable long-term solution.

The repository currently appears to have no stars, watchers or forks

which makes it difficult to assess maturity, maintenance quality, adoption, or long-term reliability.

Additionally, introducing externally maintained npm packages into an enterprise automation platform introduces its own security and supply-chain risks, especially when those packages interact with highly privileged systems such as Microsoft Graph and Teams.

Hi @Daniel_Stahl welcome to the n8n community!

From my review of the behavior and the Graph API error, this appears related to how the Teams node handles delegated OAuth scopes during token generation rather than an intentional requirement for Group.ReadWrite.All ; specifically, ChannelMessage.Send does not seem to be included in the effective access token despite being configured in the app registration, which would explain why the Microsoft Graph fallback permission check is requesting the broader scope instead.