为机器人重复使用 App Id 是好主意还是坏主意?

Is reusing an App Id for a bot a good or a bad idea?

我想为 Teams 开发和发布一个机器人,以便与我的 SaaS 交互(我已经有一个正在移植的 Slackbot)。我正在根据 this guide and came across the choice of whether to auto-generate a new App Id and password, or manually registering one (described here) 创建机器人频道注册。我已经为我的 SaaS 发布了一个 Azure AD 应用程序,该应用程序已发布到 AppSource 市场(集成目前主要允许使用您的 M365 帐户登录并从 AD 同步用户)。为我为相同 SaaS 开发的机器人使用相同的 App ID 是否可能,是否有意义?还是以某种方式不可取?与此相关的是,我是否可以扩展我在 AppSource 上的现有列表以也包含新的机器人,或者这应该是一个单独的列表?

我在 the documentation for manual registration of a bot 中注意到,它说机器人仅适用于“任何组织目录中的帐户和个人 Microsoft 帐户(例如 Xbox,Outlook.com)”- 我现有的应用程序仅适用于组织帐户,而不是个人帐户(因为它是 B2B 应用程序)- 这会改变一切吗?

  • 对任何其他 B2B 重复使用相同的 appid 不会产生任何问题。据说,如果您打算 implement/use BOT 框架,则不能使用上述应用程序,因为它仅为组织注册。

  • 如果您打算创建 BOT 相关应用程序注册,那么我会 建议您使用 Organization + 创建新的应用程序注册 适合您的个人场景。

  • 请看documentation and it's disclaimer

在上面的文档中很清楚,如果您创建任何其他应用程序注册(组织+个人除外),那么 BOT 将无法使用。

也许换个角度考虑这个问题 - 是否有充分的理由重新使用该应用程序?创建一个额外的应用程序非常容易,而且基本上是免费的,这样您就不会 运行 一个场景所需的设置现在或将来可能与另一个场景的要求相冲突的风险。不过,这里还有一些其他可能的考虑因素:

  1. 自 2020 年 11 月 9 日起,新应用需要发布者验证。这不会影响您的内部应用,可以得到全局管理员的同意。

  2. 如果您需要用户(或管理员)同意某些权限(例如委托图访问),那么使用相同的应用程序可能有意义。例如,在 Teams 上下文中,机器人和选项卡都需要代表用户从 Graph 访问某些内容。您可以在一种情况下获得同意,并使用它从两种情况下访问资源。

简而言之,尤其是如果您对当前和计划的用例都没有非常好的想法,很难给出一个非常可靠的 'yes' 或 'no'。不过,我的直觉告诉我,请为一个单独的、不相关的场景使用一个单独的应用程序。