Azure B2C 中的 KMSI 实际上做了什么？
What does KMSI in Azure B2C actually DO?
我们已获得此文档，其中解释了如何使用自定义策略设置保持登录状态 (KMSI)：
https://docs.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-keep-me-signed-in
好的，太好了，所以我们现在知道如何使用（烦人的复杂）XML 策略文件来设置一些 UI 的复选框。 但是这实际上是做什么的？这方面的信息在哪里？
- 是否为客户端提供新的 ID Token 而无需重新授权？
- 是否提供新的auth_code？
- 是否使用隐藏的 i 帧？
- 客户端应用程序实际上 called/accomplished 刷新是怎样的？ (SPA)
- 是否需要到 B2C 的往返行程，它只是不要求用户提供信用并将其直接重定向回应用程序？或者应用程序是否能够完全 UI/UX 无声地发出刷新请求？如果是这样，如何？ API 在哪里？需要 MSAL.js 中的内容吗？
- 为什么仅限本地？如果B2C是“中间人”IDP，它发行的token是自己的（当然不是真的来自社交账号），那为什么不能这样刷新token for all 帐户类型（本地或社交）？
我的理解是，对于隐式授予，存储刷新令牌是不可能的，因此保留一个会话 cookie 并使用它通过带有 prompt=none 的 i-frame 获取新会话是一个 HACK能够保持会话 cookie 更新和最新。
这是前 MS（现为 Auth0）身份大师 Vittorio 的文章：
https://auth0.com/blog/oauth2-implicit-grant-and-spa/
他通过刷新令牌轮换提到“更新访问令牌”。这被描述为：
"a feature that invalidates a refresh token and issues a new one
whenever it is used to refresh an access token"
这似乎是通过会话 cookie 和 i-frame“hack”（与隐式授权一起使用）来完成的，returns 一个新的授权代码，（大概）可以用来获取一个新的访问令牌。
为什么我们现在有了 PKCE 还需要这个？ 显然，即使使用 PKCE，在浏览器中存储长期存在的刷新令牌仍然不好。我找到 undocumented information that B2C Refresh Tokens for SPA max lifetime is 24 hours (not 90 days, and not configurable).
那么我们今天是否仍在进行此会话 cookie 隐藏 i 帧黑客攻击？即使有 PKCE？这就是 B2C KMSI 正在做的事情吗？如果是这样，它是如何触发的，我的应用程序如何实际获得新的访问令牌以用于我的 API?
底线： 我需要让我的用户保持签名并能够访问我的安全网络 API 而无需重新授权，即使他们不再打开我的应用程序超过 100 天。理想情况下，这应该完全安静地完成，没有往返，无论帐户是本地帐户还是 IDP 端的社交帐户。 B2C KMSI 功能是否适用于此？
KMSI/No KMSI 影响 AAD B2C 在客户端上设置其 Web 会话 cookie 的方式。
KMSI：为您想要的时间段设置持久会话 cookie。这意味着用户在下次访问您的网站时不需要向 AAD B2C 重新提供凭据，即使他们关闭了浏览器也是如此。您可以将其设置的最长时间约为 65 岁。
无 KMSI：设置会话 cookie（非持久性）。
如果用户关闭浏览器，则在下次访问您的网站时必须向 AAD B2C 出示其凭据。如果他们没有关闭浏览器，只是关闭选项卡，那么他们可以在不重新提供您网站的凭据的情况下登录的最长时间为 24 小时。
KMSI + 隐式流 (SPA) - 以上规则适用于登录和令牌更新操作。使用隐藏的 iframe 并依赖于 AAD B2C cookie。使用隐藏的 iframe，它使用 AAD B2C 会话 cookie 来发出新的 AT。
KMSI + PKCE (SPA) - 对于刷新令牌有效的令牌更新，忽略上述规则。以上规则仅在 Refresh Token 过期或不存在时适用，这是回退。否则，它们不适用，因为刷新令牌流不依赖于 cookie。最长 24 小时刷新令牌。使用隐藏的 iframe 并处理 OIDC 刷新令牌流。但是当处理 AAD B2C 会话 cookie 时，您将获得一个新的授权码。
KMSI + Code/PKCE（Web 应用程序）- 对于刷新令牌有效的令牌续订，上述规则将被忽略。以上规则仅在刷新令牌过期或不存在时适用。否则，它们不适用，因为刷新令牌不依赖于 cookie。 Max refresh token 90days 之后你回退到 cookie。但是当处理 AAD B2C 会话 cookie 时，您将获得一个新的授权码。
KMSI 不适用于社交帐户，因为 AAD B2C 始终依赖于社交帐户会话。如果 AAD B2C 让您保持登录状态但您的帐户在联合 IdP 处被删除，这将是一个安全漏洞。您可以调整会话管理以忽略对社交 IdP 的回调，但是 select KMSI 没有针对社交 IdP 的用户体验，现在也无法以编程方式完成。
由于 KMSI 围绕会话 cookie，因此仅在执行到 AAD B2C 的往返行程时才对其进行评估。
那是当你的刷新令牌过期（Code/PKCE 流）或者你想要一个新的访问令牌（隐式），或者你正在做一个新的登录。这些场景涉及处理 AAD B2C 会话 cookie 的往返行程。
您不需要以任何方式配置 MSAL 以与您的 KMSI 配置相关联。 AAD B2C 本身会在需要时处理 cookie。
由于您使用的是 SPA + PKCE，因此您希望最大化会话生命周期，因为它是 RT 流程的回退（最长 24 小时），但会话生命周期也只有最长 24 小时。因此，您被迫使用 KMSI 为您提供长达 65 年的会话生命周期，代价是该会话即使在浏览器关闭后仍然存在。每次 (AT) 过期（最多 24 小时）时，将有一个隐藏的 iframe 获取新的访问令牌，如果 RT 也过期（最多 24 小时），则使用刷新令牌或 cookie。
它是如何触发的 - MSAL 库知道访问令牌的有效性并在需要时执行所需的刷新令牌调用。 AAD B2C 验证 RT，否则回退到会话 cookie。因此，无需更改代码即可适应任何此逻辑。
在您的 SPA 中对您的 API 的每次调用都应该在 API 请求本身之前使用适当的范围调用 acquireTokenSilent() 。 MSAL 确定是否存在有效的 AT，只有在不存在时才发出网络请求。
我们已获得此文档，其中解释了如何使用自定义策略设置保持登录状态 (KMSI)： https://docs.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-keep-me-signed-in
好的，太好了，所以我们现在知道如何使用（烦人的复杂）XML 策略文件来设置一些 UI 的复选框。 但是这实际上是做什么的？这方面的信息在哪里？
- 是否为客户端提供新的 ID Token 而无需重新授权？
- 是否提供新的auth_code？
- 是否使用隐藏的 i 帧？
- 客户端应用程序实际上 called/accomplished 刷新是怎样的？ (SPA)
- 是否需要到 B2C 的往返行程，它只是不要求用户提供信用并将其直接重定向回应用程序？或者应用程序是否能够完全 UI/UX 无声地发出刷新请求？如果是这样，如何？ API 在哪里？需要 MSAL.js 中的内容吗？
- 为什么仅限本地？如果B2C是“中间人”IDP，它发行的token是自己的（当然不是真的来自社交账号），那为什么不能这样刷新token for all 帐户类型（本地或社交）？
我的理解是，对于隐式授予，存储刷新令牌是不可能的，因此保留一个会话 cookie 并使用它通过带有 prompt=none 的 i-frame 获取新会话是一个 HACK能够保持会话 cookie 更新和最新。
这是前 MS（现为 Auth0）身份大师 Vittorio 的文章： https://auth0.com/blog/oauth2-implicit-grant-and-spa/
他通过刷新令牌轮换提到“更新访问令牌”。这被描述为：
"a feature that invalidates a refresh token and issues a new one whenever it is used to refresh an access token"
这似乎是通过会话 cookie 和 i-frame“hack”（与隐式授权一起使用）来完成的，returns 一个新的授权代码，（大概）可以用来获取一个新的访问令牌。
为什么我们现在有了 PKCE 还需要这个？ 显然，即使使用 PKCE，在浏览器中存储长期存在的刷新令牌仍然不好。我找到 undocumented information that B2C Refresh Tokens for SPA max lifetime is 24 hours (not 90 days, and not configurable).
那么我们今天是否仍在进行此会话 cookie 隐藏 i 帧黑客攻击？即使有 PKCE？这就是 B2C KMSI 正在做的事情吗？如果是这样，它是如何触发的，我的应用程序如何实际获得新的访问令牌以用于我的 API?
底线： 我需要让我的用户保持签名并能够访问我的安全网络 API 而无需重新授权，即使他们不再打开我的应用程序超过 100 天。理想情况下，这应该完全安静地完成，没有往返，无论帐户是本地帐户还是 IDP 端的社交帐户。 B2C KMSI 功能是否适用于此？
KMSI/No KMSI 影响 AAD B2C 在客户端上设置其 Web 会话 cookie 的方式。
KMSI：为您想要的时间段设置持久会话 cookie。这意味着用户在下次访问您的网站时不需要向 AAD B2C 重新提供凭据，即使他们关闭了浏览器也是如此。您可以将其设置的最长时间约为 65 岁。
无 KMSI：设置会话 cookie（非持久性）。 如果用户关闭浏览器，则在下次访问您的网站时必须向 AAD B2C 出示其凭据。如果他们没有关闭浏览器，只是关闭选项卡，那么他们可以在不重新提供您网站的凭据的情况下登录的最长时间为 24 小时。
KMSI + 隐式流 (SPA) - 以上规则适用于登录和令牌更新操作。使用隐藏的 iframe 并依赖于 AAD B2C cookie。使用隐藏的 iframe，它使用 AAD B2C 会话 cookie 来发出新的 AT。
KMSI + PKCE (SPA) - 对于刷新令牌有效的令牌更新，忽略上述规则。以上规则仅在 Refresh Token 过期或不存在时适用，这是回退。否则，它们不适用，因为刷新令牌流不依赖于 cookie。最长 24 小时刷新令牌。使用隐藏的 iframe 并处理 OIDC 刷新令牌流。但是当处理 AAD B2C 会话 cookie 时，您将获得一个新的授权码。
KMSI + Code/PKCE（Web 应用程序）- 对于刷新令牌有效的令牌续订，上述规则将被忽略。以上规则仅在刷新令牌过期或不存在时适用。否则，它们不适用，因为刷新令牌不依赖于 cookie。 Max refresh token 90days 之后你回退到 cookie。但是当处理 AAD B2C 会话 cookie 时，您将获得一个新的授权码。
KMSI 不适用于社交帐户，因为 AAD B2C 始终依赖于社交帐户会话。如果 AAD B2C 让您保持登录状态但您的帐户在联合 IdP 处被删除，这将是一个安全漏洞。您可以调整会话管理以忽略对社交 IdP 的回调，但是 select KMSI 没有针对社交 IdP 的用户体验，现在也无法以编程方式完成。
由于 KMSI 围绕会话 cookie，因此仅在执行到 AAD B2C 的往返行程时才对其进行评估。 那是当你的刷新令牌过期（Code/PKCE 流）或者你想要一个新的访问令牌（隐式），或者你正在做一个新的登录。这些场景涉及处理 AAD B2C 会话 cookie 的往返行程。
您不需要以任何方式配置 MSAL 以与您的 KMSI 配置相关联。 AAD B2C 本身会在需要时处理 cookie。
由于您使用的是 SPA + PKCE，因此您希望最大化会话生命周期，因为它是 RT 流程的回退（最长 24 小时），但会话生命周期也只有最长 24 小时。因此，您被迫使用 KMSI 为您提供长达 65 年的会话生命周期，代价是该会话即使在浏览器关闭后仍然存在。每次 (AT) 过期（最多 24 小时）时，将有一个隐藏的 iframe 获取新的访问令牌，如果 RT 也过期（最多 24 小时），则使用刷新令牌或 cookie。
它是如何触发的 - MSAL 库知道访问令牌的有效性并在需要时执行所需的刷新令牌调用。 AAD B2C 验证 RT，否则回退到会话 cookie。因此，无需更改代码即可适应任何此逻辑。
在您的 SPA 中对您的 API 的每次调用都应该在 API 请求本身之前使用适当的范围调用 acquireTokenSilent() 。 MSAL 确定是否存在有效的 AT，只有在不存在时才发出网络请求。