如果我们使用 OAuth 代码流程，用户会在 Teams 个人应用程序中提示再次输入密码（即使已登录 Teams 应用程序）

Question

我们创建了一个 Teams 个人应用程序，该应用程序已在 Teams 应用商店中发布。我们遵循的身份验证机制基于OAuth代码流，其中我们使用Teams js sdk提供的authenticate.authenticate()函数来打开Microsoft登录页面。我们指定所有必需的参数，如租户 id、client_id 等，以及 login_hint。这将打开一个带有 login.microsoft.com url 的新窗口，用户直接在 Teams 桌面和浏览器（Windows 和 Linux）中进行身份验证，即打开的窗口会自行关闭，用户无需输入他的密码再次凭证。

但在 Mac 设备和移动设备中，打开的窗口不会自行关闭，并要求用户再次输入密码，尽管已在 Teams 应用程序中登录。

如何避免在 Mac 和移动设备中通过用户交互来获取 oauth 代码？

我们确实有方法以静默方式获取 AD 令牌，但我们认为在客户端代码中获取具有很大范围的 AD 令牌并在每次令牌过期时向后端发送新令牌并不是一个好主意。 有没有什么方法可以让我们在 Teams 个人应用程序中静默获取 oauth 代码，而无需用户交互？ 或者还有其他方法可以处理这种情况吗？

Answer 1

如果我根据后续详细信息正确理解了您的场景（感谢您提供它们！），那么 Teams 应用程序处理此问题的规范方法是结合使用 team-js 启用的 SSO 流程和

-（OBO）流程。您可以在SSO 概述页面阅读有关利用 SSO 的完整详细信息，然后了解如何使用扩展选项卡应用程序页面中描述的模式扩展它以调用其他端点（例如 MS Graph）。

流程概述：

您的 Teams 应用程序调用
1. authentication.getAuthToken。此函数将为您在应用程序清单的 webApplicationInfo 部分中指定的资源返回颁发给 Teams 的身份验证令牌。该资源应该是您的后端/中间层服务。
您的团队应用程序将此令牌发送到您的后端。
您的后端执行 OBO 流程以将该代币交换为新代币。这个新令牌将颁发给您实际想要访问的资源的服务（例如示例中的 Calendar.Read ）。此 OBO 流的输出既是访问令牌又是
3. 刷新令牌。如果访问令牌过期，您的后端可以使用刷新令牌获取另一个令牌。
您的后端使用该令牌来访问所需的资源。

最终刷新令牌也将过期。在这种情况下，您的后端将需要来自客户端的新令牌（重复上述步骤）。不过，这种情况应该很少见。

使用此流程时，Teams 应用程序的用户通常不会看到任何身份验证/登录 UI（由于初始同意提示或其他提示（例如多因素身份验证），可能会出现

一些一次性或不频繁的 UI 中断） ）取决于租户的配置）。客户端上不需要存储任何客户端机密或其他敏感信息。最后，虽然所有令牌最终都会过期，但利用作为 OBO 流程一部分收到的刷新令牌将最大限度地减少不断从客户端检索和发送令牌的需要。