即使用户正在积极使用应用程序，Azure AD Easy Auth 也会过期

Question

我们有一个使用Azure Active Directory“Easy Auth”的单页应用程序（SPA），例如无代码解决方案。当用户第一次打开应用程序时，这似乎工作正常。他们将被重定向到 Microsoft 登录页面，他们可以进行身份​​验证，然后访问应用程序。

然后，由于它是 SPA，用户将四处导航并仅触发 Ajax 请求。大约 24 小时后，当会话 cookie 过期时，问题就会出现。用户可能仍然打开相同的浏览器选项卡，并且不执行整个页面刷新。然后他们可能正在处理一条记录，并且在某个时候他们的下一个 Ajax PUT 请求失败并出现重定向 HTTP 状态，并且他们失去了工作。

所以他们的关键问题是：

我们如何使 SPA Ajax 请求扩展当前用户的会话，以便他们的会话在主动使用应用程序时不会过期？

Azure AD Easy Auth 服务似乎并不“尊重”用户的活动，这使我们相信会话 cookie 永远不会更新。

注意：我们最近使用 /.auth/refresh 端点进行了一些测试，但这也不能解决问题。

Answer 1

有几种方法可以解决这个问题。以下是我能想到的一些：

1. 使用本地存储：您提到的问题是用户由于重定向而丢失了工作。如果您将正在进行的状态保留在本地存储中，以便在重定向回页面时可用，则可以解决丢失工作的问题。
2. 切换到使用令牌：/.auth/refresh使用 AAD 时，端点不会刷新 AppServiceAuthSession，因为 AAD 不支持刷新用户信息。您可以做的是使用x-zumo-auth令牌向后端进行身份验证。端点/.auth/refresh将正确刷新这些令牌。如果您使用 显式登录用户/.auth/login/aad，那么您可以添加session_mode=token作为查询字符串参数。如果您使用Mobile Apps JavaScript SDK，则可以为您完成此操作。如果登录是自动的，那么您需要添加session_mode=token身份additionalLoginParams验证配置的设置。然后，您可以从登录完成后添加到 URL 的 #token 片段中解析身份验证令牌。
3. 使用隐藏的 iframe：我自己还没有尝试过，但如果你能让它工作，可能需要最少的代码更改。这个想法是，当您检测到用户处于活动状态时，您可以使用隐藏的 iframe 定期重新登录用户。iframe 需要指向用户电子邮件地址最后一部分之类的内容 - 例如 contoso.com ./auth/login/aad?prompt=none&domain_hint={userdomain.com}。{userdomain.com}这些参数将传递到 AAD 登录页面，登录应自动完成，无需任何用户交互。在浏览器窗口中手动测试几次，以确保其正常工作。结果应该是更新后的身份验证 cookie，并且具有新的过期时间。

如果您对这些选项有任何疑问或问题，请在评论中告诉我。