【问题标题】:ADB2C refresh_token always expires in one dayADB2C refresh_token 总是在一天后过期
【发布时间】:2021-04-13 04:57:21
【问题描述】:

我一直在为 adb2c 苦苦挣扎。特别是刷新流程。我正在使用最新版本的msal-browser,一切正常,刷新令牌效果很好。唯一的问题是令牌端点返回一个总是会在一天后过期的refresh_token。在这种情况下,用户只能登录一天,之后,用户将始终需要重新授权。这是端点的示例以及它在登录后直接返回的内容。(请注意,出于测试目的,我已将 access_token 过期时间设置为 5 分钟)

端点:

https://{b2c_domain.onmicrosoft.com/{b2c_policy}/oauth2/v2.0/token

回复:

{
    "access_token": "{access_token_hidden}",
    "id_token": "{id_token_hidden}",
    "token_type": "Bearer",
    "not_before": 1610023338,
    "expires_in": 300,
    "expires_on": 1610023638,
    "resource": "{resource_hidden}",
    "client_info": "{client_info}",
    "scope": "https://{adb2c_domain_hidden}.onmicrosoft.com/api/user_impersonation",
    "refresh_token": "{refresh_token_hidden}",
    "refresh_token_expires_in": 86400
}

当应用程序在某个时候尝试刷新令牌时,它会再次调用令牌端点。这是第二个响应的样子:

{
    "access_token": "{access_token_hidden}",
    "id_token": "{id_token_hidden}",
    "token_type": "Bearer",
    "not_before": 1610023891,
    "expires_in": 300,
    "expires_on": 1610024191,
    "resource": "{resource_hidden}",
    "client_info": "{client_info}",
    "scope": "https://{adb2c_domain_hidden}.onmicrosoft.com/api/user_impersonation",
    "refresh_token": "{refresh_token_hidden}",
    "refresh_token_expires_in": 85846
}

refresh_token_expires_in 没有滚动。但这是可以理解的,用户不应该始终保持登录状态。但是,在我的 adb2c 策略中,以下设置处于活动状态:

我会假设,正如我在设置中配置的那样,刷新令牌应该至少激活 14 天。如果没有,甚至长达 90 天?我可以使用这些设置,但它总是会给我一个持续 1 天的 refresh_token。有没有人有这方面的经验或有可能的解决方案?谢谢!

【问题讨论】:

    标签: azure oauth azure-ad-b2c


    【解决方案1】:

    是的,如您所想,lifetime of the refresh token 最长可达 90 天。如果您需要配置刷新令牌的生命周期,您应该使用 powershell 创建令牌生命周期策略,然后将该策略分配给您的服务主体以设置令牌生命周期。见:here


    更新:

    我刚刚使用Azure AD B2C门户将刷新令牌的生命周期设置为14天,然后用ROPC user flow进行测试,结果确实生效了。我得到的刷新令牌是 14 天。

    所以,请确保您为刷新令牌设置生命周期的用户流是您正在使用的用户流,这一点非常重要!

    顺便说一句,你的端点错了,应该是:

    https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/{b2c_policy}/oauth2/v2.0/token
    

    2.

    3.

    【讨论】:

    • 但是为什么 ADB2C 提供一个允许您配置令牌生命周期的 UI?这些设置也应该有效?
    • 感谢您更新的答案!该应用程序是一个 SPA,我们使用的是 PKCE 流程。您的回答不适用于我们目前的情况。
    【解决方案2】:

    如果您使用的是在 SPA 应用程序中实现 带有 PKCE 的代码授权 的 Msal-Browser。对于这种情况,您将获得 24 小时到期且不会滚动的刷新令牌。 24 小时后,您需要转到 azure ad 的 /authorization 端点以获取新的访问和刷新令牌。如果浏览器具有有效的登录会话,这也可以是非交互式流程。

    在 Msal 浏览器库中,如果您已配置会话超过 24 小时,则可以使用 ssoSilent() 执行静默登录,它需要您发送 login_hint。

    【讨论】:

    • 是的,我们是 PKCE 流程。这太糟糕了。有没有办法让刷新令牌滚动? 24小时后的授权怎么可能是非交互的,是通过隐藏的iframe吗?
    • 在隐式流程中,刷新令牌使用发生在隐藏的 iframe 中,进一步第三方 cookie 将被阻止,因此这是不可能的。如果浏览器中存在用户会话,您仍然可以使用非交互流来获取令牌。无法找到 b2c 文档,但逻辑将保持不变参考:docs.microsoft.com/en-us/azure/active-directory/develop/…
    • 我正在努力解决同样的问题。当用户在初始登录后 24 小时关闭浏览器并返回应用程序时,需要进行交互式登录。那是糟糕的用户体验。有没有办法让 B2C 会话持久化? Azure AD 可以保持登录状态,为什么 B2C 不能?
    • 出于安全原因,他们减少了 SPA 应用程序的刷新令牌寿命,但在 PKCE 中,您有两件事可以执行非交互式流程。刷新令牌和浏览器会话。以前,您在隐式流中只有一个浏览器会话。在新版本的库中,您可以 ssoSilent,登录会话可用,然后这将非交互地发生。
    • 参考 Msal-browser 文档以获取有关库中公开 api 的更多详细信息。
    猜你喜欢
    • 2020-06-01
    • 1970-01-01
    • 1970-01-01
    • 2022-12-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-03-14
    • 2012-05-02
    相关资源
    最近更新 更多