azure-ad-b2c - 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？

是否使用了隐藏的 i-frame？

如何从客户端应用程序实际调用/完成刷新？ (SPA)

是否需要往返 B2C，它只是不要求用户提供凭据并将它们直接重定向回应用程序？或者应用程序是否能够使刷新请求完全 UI/UX 静默？如果是这样，如何？ API在哪里？是否需要 MSAL.js 中的某些内容？

为什么只有本地？如果 B2C 是“中间人”IDP，并且它发行的代币是它自己的(当然实际上不是来自社交帐户)，那么为什么不能以这种方式为所有帐户类型(本地或社交)刷新代币？

我的理解是，对于隐式授予，存储刷新 token 是不可能的，因此保留一个 session cookie 并使用它通过 i-frame 获取新 session prompt=none是一个能够保持 session cookie 更新和最新的 HACK。
这是前 MS(现为 Auth0)身份专家 Vittorio 的一篇文章:
https://auth0.com/blog/oauth2-implicit-grant-and-spa/
他提到“ 更新访问 token ” 刷新 token 轮换 .这被描述为:

"a feature that invalidates a refresh token and issues a new onewhenever it is used to refresh an access token"

这似乎是通过 session cookie 和 i-frame“hack”(与隐式授权一起使用)来完成的，它返回一个新的授权代码，(大概)可以用来获取新的访问 token 。
当我们现在拥有 PKCE 时，为什么需要这样做？ 显然，即使使用 PKCE，在浏览器中存储长期存在的刷新 token 仍然很糟糕。我找到了 undocumented information那个 SPA 最大生命周期的 B2C 刷新 token 为 24 小时 (不是 90 天，还有 not configurable )。
那么我们今天还在做这个 session cookie 隐藏的 i-frame hack 吗？即使使用 PKCE？这就是 B2C KMSI 正在做的事情吗？如果是这样，它是如何触发的，我的应用程序如何实际获得新的访问 token 以用于我的 API？
底线:即使他们 100 多天没有再次打开我的应用程序，我也需要让我的用户保持签名并能够访问我的安全 Web API，而无需重新进行身份验证。理想情况下，这应该完全安静地完成，没有往返，无论帐户是本地帐户还是 IDP 方面的社交帐户。 B2C KMSI 功能是否为此提供了正确的机制？

Answer 1

KMSI/No KMSI 会影响 AAD B2C 如何在客户端上设置其 Web session cookie。
KMSI:在您想要的时间段内设置持久 session cookie。这意味着用户下次访问您的网站时无需向 AAD B2C 重新提供凭据，即使他们关闭了浏览器。您可以将其设置为的最长时间约为 65 年。
无 KMSI:设置 session cookie(非持久性)。
如果用户关闭了浏览器，他们必须在下次访问您的网站时向 AAD B2C 出示他们的凭据。如果他们没有关闭浏览器，只是关闭选项卡，那么他们可以在不重新提供您网站凭据的情况下登录的最长时间为 24 小时。
KMSI + 隐式流 (SPA) - 以上规则适用于登录和 token 更新操作。使用隐藏的 iframe 并依赖于 AAD B2C cookie。使用隐藏的 iframe，它使用 AAD B2C session cookie 来发出新的 AT。
KMSI + PKCE (SPA) - 对于刷新 token 有效的 token 续订，上述规则将被忽略。以上规则仅适用于 Refresh Token 过期或不存在的情况，这是后备。否则，它们不适用，因为刷新 token 流不依赖于 cookie。最多 24 小时刷新 token 。使用隐藏的 iframe 并处理 OIDC 刷新 token 流。但是当 AAD B2C session cookie 被处理时，您将获得一个新的 Auth Code。
KMSI + 代码/PKCE(Web 应用程序)- 对于刷新 token 有效的 token 续订，将忽略上述规则。以上规则仅适用于刷新 token 过期或不存在的情况。否则，它们不适用，因为刷新 token 不依赖于 cookie。最大刷新 token 90 天后您回退到 cookie。但是当 AAD B2C session cookie 被处理时，您将获得一个新的 Auth Code。
KMSI 不适用于社交帐户，因为 AAD B2C 始终依赖于社交帐户 session 。如果 AAD B2C 让您保持登录状态，但您的帐户在联合 IdP 处被删除，这将是一个安全漏洞。您可以调整 session 管理以忽略回拨到社交 IdP，但没有 UX 可以为社交 IdP 选择 KMSI，现在也无法以编程方式完成。
由于 KMSI 围绕 session cookie，因此仅在执行到 AAD B2C 的往返时才会对其进行评估。
那是当您的刷新 token 过期(代码/PKCE 流程)或者您想要一个新的访问 token (隐式)，或者您正在重新登录时。这些场景涉及处理 AAD B2C session cookie 的往返。
您无需以任何方式配置 MSAL 即可与您的 KMSI 配置相关联。 AAD B2C 本身会在需要时处理 cookie。
由于您使用的是 SPA + PKCE，您希望最大化 session 生命周期，因为它是 RT 流程的回退(最长 24 小时)，但 session 生命周期也只有最长 24 小时。因此，您被迫使用 KMSI 为您提供长达 65 年的 session 生命周期，代价是即使在浏览器关闭后该 session 仍然存在。如果 RT 也过期(最多 24 小时)，则每次 (AT) 到期(最多 24 小时)时，都会有一个隐藏的 iframe 使用刷新 token 或 cookie 获取新的访问 token 。
如何触发 - MSAL 库知道访问 token 的有效性并在需要时执行所需的刷新 token 调用。 AAD B2C 验证 RT，否则回退到 session cookie。因此，无需更改代码即可适应任何这种逻辑。
在您的 SPA 中对您的 API 的每次调用都应在 API 请求本身之前使用适当的范围调用 AcquireTokenSilent()。 MSAL 确定是否存在有效的 AT，如果不存在，则仅发出网络请求。