oauth-2.0 - 使用 AD FS 4.0 (2016) 或更高版本获取新的刷新 token

Question

我将 AD FS 2016 配置为支持通过 OAuth2/OpenID Connect 使用授权码授予和 PKCE 对“ native 应用程序”进行身份验证。我通过设置以下内容创建了一个依赖方并配置(出于测试目的) token 生命周期:

Set-AdfsRelyingPartyTrust -TargetName MyRPT -IssueOAuthRefreshTokensTo AllDevices -TokenLifetime 3

Grant-AdfsApplicationPermission -ClientRoleIdentifier MyClient -ServerRoleIdentifier MyRPT -ScopeNames openid,profile,email

Set-AdfsProperty -SSOLifetime 7 -PersistenSsoEnabled $false

...这为我提供了在 3 分钟后过期的访问/ID token 和在 7(实际上是 14，见下文)分钟后过期的刷新 token 。我还禁用了 Persistent SSO，所以我没有得到 session cookie。一切顺利。

身份验证成功后，我的客户端向/oauth2/token 端点发出 POST 请求，并传递以下参数:

• client_id: "我的客户"
• 代码:...
• redirect_uri: ...
• code_verifier: ...
• grant_type: "authorization_code"

我收到了以下内容的有效回复:

{
  "access_token": "...",
  "token_type": "bearer",
  "expires_in": 180,
  "resource": "MyRPT",
  "refresh_token": "...",
  "refresh_token_expires_in": 419,
  "scope": "email profile openid",
  "id_token": "..."
}

太棒了。

然后在访问 token 到期前大约 10 秒，客户端向/oauth2/token 发出另一个 POST 请求，这次带有以下参数:

• refresh_token: ...
• grant_type: "refresh_token"
• client_id: "我的客户"

并返回以下成功响应:

{
  "access_token": "...",
  "token_type": "bearer",
  "expires_in": 180,
  "id_token": "..."
}

请注意，这次没有返回刷新 token 。同样的事情又发生了四次(总共大约 14 分钟，所以 SSOLifetime 两倍？)而刷新 token 仍然有效，最后，在第四次请求新访问 token 时我得到以下主体出现 400 错误:

{
  "error":"invalid_grant",
  "error_description":"MSIS9615: The refresh token received in \u0027refresh_token\u0027 parameter has expired."
}

这有点道理，但是......当当前刷新 token 接近到期时间时，不应该发布一个新的刷新 token 吗？

Official Docs在这件事上有些神秘:

Although refresh tokens aren't revoked when used to acquire newaccess tokens, you are expected to discard the old refresh token. Asper the OAuth 2.0 spec says: "The authorization server MAY issue a newrefresh token, in which case the client MUST discard the old refreshtoken and replace it with the new refresh token. The authorizationserver MAY revoke the old refresh token after issuing a new refreshtoken to the client." AD FS issues refresh token when the new refreshtoken lifetime is longer than previous refresh token lifetime. To viewadditional information on AD FS refresh token lifetimes, visit AD FSSingle Sign On Settings.

呃，什么？让我用伪代码来写:

if (newRefreshTokenLifetime > previousRefreshTokenLifetime) {
  issueNewRefreshToken();
}

...但那会是总是，不是吗？

关于如何配置 AD FS 以便它在需要时也发出新的刷新 token 的任何想法？理想情况下，最好有 refresh token rotation , 但一次做一件事...

Answer 1

通常在 OAuth 中，刷新 token 的生命周期是在授权时设置的，当用户登录时，他们可能同意在特定时间使用特定权限。

因此，如果用户在 09:00 登录 8 小时 session ，并且他们的应用程序在 10:00 刷新访问 token ，如果发布了新的刷新 token ，则它应该可以使用 7 小时。也就是说，您不能在不让用户再次参与的情况下覆盖初始授权。

如您所说，较新的趋势是在每次访问 token 刷新时获取一个新的刷新 token ，但这只是一种保护机制，ADFS 不支持该机制。所以我会按如下方式进行:

• 将 SSO 生命周期设置为所需值，例如 8 小时，并将访问 token 生命周期设置为标准值，例如 30 分钟
• 以面向 future 的方式编写代码，在获得新 token 时丢弃现有的刷新 token

在 native 应用程序中刷新 token

根据评论，您正在尝试使用 PKCE 并希望使用旋转刷新 token ，但 ADFS 不支持后者，因此您不能。

您有一个原生应用，其标准解决方案始终是将刷新 token 存储在仅对应用和用户可用的安全操作系统存储中。刷新 token 是否轮换应该无关紧要。示例:

• Desktop App
• iOS App
• Android App

SPA

token 和浏览器是一个完全不同的话题，因为没有安全的地方可以存储刷新 token 。由于最近对第三方 cookie 浏览器的限制，让 Javascript 应用程序运行的唯一方法是将刷新 token 存储在本地存储中，从安全角度来看，这是灾难性的。

这个棘手问题的最佳解决方案是使用 API 驱动的解决方案，其中实用程序 API 为 SPA 发出 SameSite=strict cookie。不过，有一些移动部件可以部署到开发人员 PC 和您的管道中。有关设计模式的详细信息，请参阅下面的 Curity 资源。这也适用于 ADFS。

• Code
• Docs