Azure B2C中的KMSI实际上是做什么的？

Question

我们有一个文档，它解释了如何使用自定义策略：https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-keep-me-signed-in来设置“保持登录”(KMSI)

好的，很好，所以我们现在知道如何使用(非常复杂的) XML策略文件来为checkbock设置一些UI。，但它到底在做什么？，这上面的信息在哪里？

• 它是否为客户端提供了一个新的ID令牌而不需要重新使用？
• 它提供了一个新的auth_code吗？
• 它用的是隐藏的I-帧吗？
• 如何从客户端应用程序实际调用/完成刷新？(水疗)
• 是否需要往返到B2C，而不要求用户提供creds并将其重定向回应用程序？或者，应用程序能够发出完全的UI/UX静默刷新请求吗？如果是这样的话，是怎么做的？API在哪里？MSAL.js中需要什么东西吗？
• 为什么只限于本地？如果B2C是“中间人”IDP，并且它发出的令牌是自己的(当然不是来自一个社会帐户)，那么为什么它不能以这种方式刷新所有帐户类型(本地的或社会化的)？

我的理解是，对于隐式格兰特来说，存储刷新令牌是不可能的，所以保持一个会话cookie并使用它使用prompt=none通过i帧获取一个新会话是一种能够保持会话cookie更新和当前的黑客。

以下是前MS (现为Auth0)身份专家Vittorio：https://auth0.com/blog/oauth2-implicit-grant-and-spa/的一篇文章

他提到了由刷新令牌旋转编写的“更新访问令牌”。这被描述为：

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

这似乎是通过会话cookie和i帧"hack“(与隐式Grant一起使用)实现的，它返回一个新的授权代码，该代码(想必)可以用来获得一个新的访问令牌。

为什么现在有PKCE?显然在浏览器中存储长寿命的刷新令牌仍然很糟糕，即使使用PKCE也是如此。我发现无证资料的B2C刷新令牌的最大生存期是24小时(不是90天，还有不可配置)。

所以我们今天还在做这个会话饼干隐藏的I-帧黑客吗？即使是PKCE？这就是B2C KMSI正在做的吗？如果是的话，它是如何触发的，以及我的应用程序如何实际获得一个新的访问令牌，以便与我的API一起使用？

的底线：，我需要让我的用户签名，并且能够访问我的安全的web而无需重新使用，即使他们在100+的日子里不再打开我的应用程序。理想情况下，这应该是完全安静地完成，没有往返，无论帐户是本地的还是社会的国内流离失所者一方。B2C KMSI特性是否是正确的机制？

Answer 1

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令牌流不依赖cookie。最多24小时刷新令牌。使用隐藏的iframe和处理OIDC刷新令牌流。但是，当AAD B2C会话cookie被处理时，您将得到一个新的Auth代码。

KMSI + Code/PKCE (Web )-在刷新令牌有效的情况下，对令牌更新忽略上述规则。以上规则仅适用于刷新令牌过期或不存在的情况。否则，它们就不适用，因为Refresh令牌不依赖cookie。最大刷新令牌90天后，您将回到cookie。但是，当AAD B2C会话cookie被处理时，您将得到一个新的Auth代码。

KMSI不适用于社会帐户，因为AAD B2C总是依赖于社会帐户会话。如果AAD B2C让您登录，但您的帐户在联邦IdP上被删除，这将是一个安全漏洞。您可以调整会话管理以忽略对社会IdP的调用，但是没有UX可以为社交IdP选择KMSI，也不能在今天以编程方式完成。

由于KMSI以会话cookie为中心，因此只有在执行到AAD B2C的往返时才会对其进行评估。这是当您的刷新令牌过期(Code/PKCE流)或您想要一个新的访问令牌(隐式)，或者您正在进行新的登录时。这些场景涉及到处理AAD B2C会话cookie的往返旅程。

您不需要以任何方式配置MSAL来绑定您的KMSI配置。AAD B2C本身在需要时处理cookies。

由于您使用的是SPA + PKCE，所以您希望最大限度地延长会话生存期，因为它是RT流(最大24小时)的回退，但会话生存期也只有最大24小时。因此，您不得不使用KMSI来给您长达65年的会话寿命，即使在浏览器关闭之后，这个会话也会持续。如果RT也过期(最多24小时)，则将有一个隐藏的iframe在每次(AT)过期(最多24小时)时使用刷新令牌或cookie获得一个新的访问令牌。

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

SPA中对API的每次调用都应该在API请求本身之前使用适当的作用域调用acquireTokenSilent()。MSAL确定是否存在有效的AT，只有在不存在时才会发出网络请求。