Azure 应用程序服务身份验证令牌在调用 uth 后未刷新。 刷新端点

Question

我有一个托管在一个azure windows应用程序服务中的角度应用程序和托管在另一个azure windows应用程序服务中的asp.net core api，两者都使用应用程序服务身份验证功能进行保护。我正在使用当前有两台服务器的应用程序服务计划。我正在使用令牌存储，它使用文件系统来存储令牌。

当 Angular 应用程序调用 api 时，它需要在授权标头中传递访问令牌。通过在 \.auth\me 端点上执行 GET 并发送 AppServiceAuthSession cookie 作为凭证来检索访问令牌。然后，返回的令牌将缓存在会话存储中并用于后续请求，直到令牌过期。当令牌过期时，我调用 \.auth efresh 端点（并发送 AppServiceAuthSession cookie），然后调用 \.auth\me 来获取刷新的令牌。

所有这些在一台服务器上运行时效果很好，但当应用程序服务计划扩展到 2 台或更多服务器时，需要调用 \.auth efresh 成功，但对 .auth\me 端点的后续调用会获取已过期的令牌。我可以通过检查内部 exp 声明来判断令牌已过期，并且对 api 的调用在正常情况下会成功时也会失败并显示 401 Unauthorized。

如果我缩减到一台服务器，问题就会消失，如果我启用 ARR 关联性，问题就会消失，但我不想仅仅为了解决这个问题而必须启用关联性。

Answer 1

对 api 的调用也会失败，并显示 401 Unauthorized，而通常会成功。

您不应该在 API 应用程序上调用

/.auth/refresh

。您必须在

WEB 应用程序

上调用 /.auth/refresh，因为身份验证令牌是在 WEB 应用程序上生成的。

承载令牌的替代方案是来自客户端请求的 AppServiceAuthSession cookie 到

/.auth/refresh

。

返回的令牌随后会缓存在会话存储中并用于后续请求，直到令牌过期。当令牌过期时，我调用 .auth efresh 端点（并发送 AppServiceAuthSession cookie），然后调用 .auth\me 来获取刷新的令牌。

我们有一个面向用户的 Web 应用程序，它调用 API 后端，后者反过来查询 MSFT 图，只是为了确保我们正确捕获了上下文。在每个阶段，我们预计会有不同的 AAD 注册：

• Web应用程序注册（需要API应用程序的权限）
• API 应用程序注册（需要 Microsoft Graph 的权限）

我们最初的假设是用户尚未明确同意使用 Microsoft Graph，因为这看起来与添加图形权限有关。由于如果您只是更新现有令牌，则用户不会参与，因此没有机会获得同意。用户需要在明确同意提示的情况下重新登录，这可以通过调用

/.auth/login/aad?prompt=consent

来完成。但我们预计这不会导致过期问题。我在这里推测，但有可能正在使用缓存的过时值来代替权限错误。需要康纳的意见。

来自实际身份验证/授权层本身的日志，特别是如果存在错误消息，是另一条有用的信息。要获取这些日志：

• 从门户中的应用程序（API 应用程序是我最感兴趣的）：“平台功能”>“诊断日志”。将“应用程序日志记录（文件系统）”更改为“打开”并将级别设置为“详细”。点击保存。
• 返回“平台功能”>“日志流”并在重现问题时保持该窗口打开（在本例中为对 API 应用程序的调用）

实际上，问题在于 AAD 不记名令牌与

/.auth/refresh

API 不兼容。相反，您必须使用会话令牌 (

_x-zumo-auth_ header

) 或会话 cookie (

_AppServiceAuthSession_ cookie

)，它们是登录活动的结果。 有关更多信息 - 请参阅此处 #refreshing-the-access-tokens

Answer 2

有点晚了，但可能对某人有用！此外，此信息基于 2021 年与 Microsoft 支持人员的一些通信，但情况可能已更改或已修复。

我认为问题在于令牌存储的配置方式。当在应用服务计划中的多个服务器上运行时，您需要将令牌存储配置为使用 blob 存储而不是使用文件存储。

配置tokenStore以使用博客存储 使用此环境变量设置 blob 存储的 url WEBSITE_AUTH_TOKEN_CONTAINER_SASURL

或者将环境变量设置为密钥保管库引用，然后该引用指向 blob 存储 url