Azure B2C 中的 KMSI 实际上有什么作用？

Question

我们提供了一份文档，其中介绍了如何使用自定义策略设置保持登录 (KMSI)： https://docs.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-keep-me-signed-in

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

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

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

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

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

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

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

当我们现在有 PKCE 时为什么需要这样做？ 显然，即使使用 PKCE，在浏览器中存储长期存在的刷新令牌仍然很糟糕。我发现undocumented information B2C Refresh Tokens for SPA max life is 24 hours（不是 90 天，not configurable）。

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

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

Answer 1

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，如果不存在则仅发出网络请求。