7

我们有这份文档解释了如何使用自定义策略设置保持登录 (KMSI)： https ://docs.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-keep -我登录

好的，太好了，所以我们现在知道如何使用（非常复杂的）XML 策略文件来为复选框设置一些 UI。但这实际上在做什么？ 这方面的信息在哪里？

  • 它是否在没有重新认证的情况下为客户提供了一个新的 ID 令牌？
  • 它是否提供了新的 auth_code？
  • 它是否使用隐藏的 i-frame？
  • 如何从客户端应用程序实际调用/完成刷新？（温泉）
  • 是否需要往返 B2C 并且它只是不向用户询问信用并将其重定向回应用程序？或者应用程序是否能够使刷新请求完全 UI/UX 静默？如果是这样，怎么做？API 在哪里？是否需要 MSAL.js 中的内容？
  • 为什么只有本地？如果 B2C 是“中间人”IDP，并且它发行的代币是它自己的（当然不是来自社交账户），那么为什么它不能以这种方式为所有账户类型（本地或社交）刷新代币？

我的理解是，对于隐式授予，存储刷新令牌是不可能的，因此保留会话 cookie 并使用它通过 i-frame 获取新会话prompt=none是一个能够保持会话 cookie 更新和最新的 HACK。

这是前 MS（现为 Auth0）身份专家 Vittorio 的文章： https ://auth0.com/blog/oauth2-implicit-grant-and-spa/

他通过Refresh Token Rotation提到了“更新访问令牌” 。这被描述为：

“一种使刷新令牌无效并在用于刷新访问令牌时发出新令牌的功能”

这似乎是通过会话 cookie 和 i-frame “hack”（与 Implicit Grant 一起使用的）完成的，它返回一个新的授权代码，该代码（大概）可用于获取新的访问令牌。

当我们现在有 PKCE 时，为什么需要这样做？ 显然，即使使用 PKCE，在浏览器中存储长期存在的刷新令牌仍然很糟糕。我发现未记录的信息表明SPA 的 B2C 刷新令牌最长生命周期为 24 小时（不是 90 天，并且不可配置）。

那么我们今天还在做这个会话 cookie 隐藏 i-frame hack 吗？即使是PKCE？这就是 B2C KMSI 正在做的事情吗？如果是这样，它是如何触发的，我的应用程序实际上如何获得一个新的访问令牌以用于我的 API？

底线：我需要让我的用户保持签名并能够访问我的安全 Web API 而无需重新授权，即使他们 100 多天没有再次打开我的应用程序。理想情况下，这应该完全无声地完成，没有往返，无论帐户是本地帐户还是 IDP 方面的社交帐户。B2C KMSI 功能是否是正确的机制？

4

1 回答 1

9

KMSI/无 KMSI 影响 AAD B2C 如何在客户端上设置其 Web 会话 cookie。

KMSI：为您想要的时间段设置持久会话 cookie。这意味着用户在下次访问您的网站时无需向 AAD B2C 重新提交凭据，即使他们关闭了浏览器。您可以将其设置为的最长时间约为 65 年。

无 KMSI：设置会话 cookie（非持久性）。如果用户关闭浏览器，他们下次访问您的网站时必须向 AAD B2C 出示他们的凭据。如果他们没有关闭浏览器，只是关闭选项卡，他们无需重新提供您网站的凭据即可登录的最长时间为 24 小时。

KMSI + 隐式流 (SPA) - 上述规则适用于登录和令牌更新操作。使用隐藏的 iframe 并依赖于 AAD B2C cookie。使用隐藏的 iframe，该 iframe 使用 AAD B2C 会话 cookie 来发出新的 AT。

KMSI + PKCE (SPA) - 对于刷新令牌有效的令牌续订，上述规则被忽略。上述规则仅适用于刷新令牌过期或不存在的情况，这是回退。否则，它们不适用，因为刷新令牌流不依赖于 cookie。最长 24 小时刷新令牌。使用隐藏的 iframe 并处理 OIDC 刷新令牌流。但是在处理 AAD B2C 会话 cookie 时，您将获得一个新的 Auth Code。

KMSI + 代码/PKCE（Web 应用程序）- 对于刷新令牌有效的令牌续订，上述规则被忽略。上述规则仅适用于刷新令牌过期或不存在的情况。否则，它们不适用，因为刷新令牌不依赖于 cookie。最大刷新令牌 90 天，之后您会回退到 cookie。但是在处理 AAD B2C 会话 cookie 时，您将获得一个新的 Auth Code。

KMSI 不适用于社交帐户，因为 AAD B2C 始终依赖于社交帐户会话。如果 AAD B2C 让您保持登录状态，但您的帐户在联合 IdP 中被删除，这将是一个安全漏洞。您可以调整会话管理以忽略对社交 IdP 的回调，但没有 UX 可以为社交 IdP 选择 KMSI，也无法以编程方式完成。

由于 KMSI 围绕会话 cookie 进行，因此仅在执行到 AAD B2C 的往返行程时对其进行评估。那是您的刷新令牌过期（代码/PKCE 流）或您想要一个新的访问令牌（隐式），或者您正在重新登录时。这些场景涉及处理 AAD B2C 会话 cookie 的往返行程。

您无需以任何方式配置 MSAL 以与您的 KMSI 配置相关联。AAD B2C 本身会在需要时处理 cookie。

由于您使用的是 SPA + PKCE，因此您希望最大化会话生命周期，因为它是 RT 流的回退（最长 24 小时），但会话生命周期也只有最长 24 小时。因此，您不得不使用 KMSI 为您提供长达 65 年的会话生命周期，代价是即使在浏览器关闭后该会话仍然存在。如果 RT 也过期（最多 24 小时），则每次（AT）过期（最多 24 小时）使用刷新令牌或 cookie 都会有一个隐藏的 iframe 来获取新的访问令牌。

它是如何触发的 - MSAL 库知道访问令牌的有效性并在需要时执行所需的刷新令牌调用。AAD B2C 验证 RT，否则回退到会话 cookie。因此，无需更改代码即可适应任何这种逻辑。

在您的 SPA 中对您的 API 的每一次调用都应该在 API 请求本身之前调用具有适当范围的 acquireTokenSilent()。MSAL 确定是否存在有效的 AT，如果不存在则仅发出网络请求。

于 2020-11-15T23:57:51.680 回答