Teams Node 需要 Group.ReadWrite.All 權限 – 企業安全顧慮

您好,

在測試 Microsoft Teams 節點進行企業部署時,我注意到該節點似乎需要 Microsoft Graph 權限 Group.ReadWrite.All,即使只是向 Teams 頻道發送訊息也是如此。

為了測試,我已經為應用程式註冊配置了以下委派範圍:

  • User.Read

  • Team.ReadBasic.All

  • ChannelMessage.Read.All

  • ChannelMessage.ReadWrite

  • ChannelMessage.Send

  • Subscription.Read.All

  • Chat.Read

從企業安全的角度來看,即使這樣配置也顯得權限過度,對於如此簡單的使用案例來說。

然而,Teams 節點仍然不能正常工作,除非授予 Group.ReadWrite.All

返回的錯誤訊息是:

請求中缺少範圍權限。API 需要 ‘ChannelMessage.Send, Group.ReadWrite.All’ 之一。請求上的範圍為 ‘ChannelMessage.Read.All, ChannelMessage.ReadWrite, Chat.Read, openid, Subscription.Read.All, Team.ReadBasic.All, User.Read, profile, email’

特別令人擔憂的是,ChannelMessage.Send 已經在應用程式註冊中配置,但顯然未包含在節點使用的有效令牌範圍中。

根據我們的測試和對 Microsoft Graph API 文件的審查,發送簡單的頻道訊息似乎不應該需要 Group.ReadWrite.All

目前看起來這可能是以下情況之一:

  • Teams 節點身份驗證/範圍處理中的錯誤

  • 或者節點本身強制執行的不必要的廣泛權限要求

從企業安全角度來看,這是一個嚴重的問題,因為 Group.ReadWrite.All 授予的是極其廣泛的租用戶範圍存取權限,違反了簡單訊息傳遞工作流程的最小權限原則。

在目前的狀態下,由於安全和合規要求,這實際上使 Teams 節點在許多企業環境中無法使用。

能否請您說明為什麼需要此權限,以及是否計畫支援更精細的權限(例如 ChannelMessage.Send)?

感謝您。

我已經檢閱過 n8n-nodes-msteams-lite 社群節點。然而,從企業安全和合規的角度來看,我不確定依賴外部社群 npm 套件是否是一個可行的長期解決方案。

該儲存庫目前似乎沒有星標、監視者或分支

這使得難以評估其成熟度、維護品質、採用情況或長期可靠性。

此外,將外部維護的 npm 套件引入企業自動化平台會帶來自身的安全和供應鏈風險,特別是當這些套件與 Microsoft Graph 和 Teams 等高度特權的系統互動時。

Hi @Daniel_Stahl 歡迎加入 n8n 社群!

從我對行為的審查和 Graph API 錯誤來看,這似乎與 Teams 節點在令牌生成期間如何處理委派的 OAuth 範圍有關,而不是對 Group.ReadWrite.All 的有意要求;具體來說,ChannelMessage.Send 似乎未包含在有效的訪問令牌中,儘管已在應用程式註冊中配置,這將解釋為什麼 Microsoft Graph 後備權限檢查改為請求更廣泛的範圍。