我想为 Teams 开发和发布一个机器人，以便与我的 SaaS 交互(我已经有一个正在移植的 Slackbot)。我正在根据 this guide 创建机器人 channel 注册并遇到了是自动生成新的 App Id 和密码，还是手动注册的选择(描述 here)。我已经为我的 SaaS 发布了一个 Azure AD 应用程序，该应用程序已发布到 AppSource 市场(集成目前主要允许使用您的 M365 帐户登录并从 AD 同步用户)。为我为相同 SaaS 开发的机器人使用相同的 App ID 是否可能，是否有意义？还是以某种方式不可取？与此相关的是，我是否可以扩展我在 AppSource 上的现有列表以也包含新的机器人，或者这应该是一个单独的列表？
我注意到 the documentation for manual registration of a bot ，它说机器人只适用于“任何组织目录中的帐户和个人 Microsoft 帐户(例如 Xbox、Outlook.com)”——我现有的应用程序只适用于组织帐户，而不适用于个人帐户(因为它是 B2B 应用程序)——确实如此改变事情？
最佳答案
或许换个角度考虑这个问题——是否有充分的理由重新使用该应用程序？创建一个额外的应用程序非常简单，而且基本上是免费的，这样一来，您就不会冒这样的风险，即现在或将来，一个场景所需的设置可能会与另一个场景的要求发生冲突。不过，这里还有一些其他可能的考虑因素:
自 2020 年 11 月 9 日起，新应用需要发布者验证。这不会影响您的内部应用，可以得到全局管理员的同意。
如果您需要用户(或管理员)同意某些权限集(例如委托(delegate) Graph 访问)，那么使用相同的应用程序可能有意义。例如，在 Teams 上下文中，机器人和选项卡都需要代表用户从 Graph 访问某些内容。您可以在一种情况下获得同意，然后使用它从两种情况下访问资源。
简而言之，尤其是如果您对当前和计划的用例都没有非常好的想法，就很难给出一个真正可靠的"is"或“否”。不过，我的直觉是为一个单独的、不相关的场景使用一个单独的应用程序。
关于microsoft-graph-api - 为机器人重复使用 App Id 是好主意还是坏主意？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/64991459/