使用ADFS4.0 (2016)或更高版本获得新的刷新令牌

Question

我将AD FS 2016配置为使用带有PKCE的授权代码授予通过OAuth2/OpenID连接来支持“本机应用程序”的身份验证。我创建了一个依赖方，并通过以下设置配置了令牌生存期(用于测试)：

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

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

Set-AdfsProperty -SSOLifetime 7 -PersistenSsoEnabled $false

...and给我3分钟后到期的访问/ID令牌，7分钟后过期的刷新令牌(实际上是14分钟)。我还禁用了持久性SSO，因此没有会话cookie。一切都很好。

成功身份验证后，我的客户端向/OAuth2/令牌端点发出POST请求，传递以下参数：

• client_id："MyClient“
• 代码：..。
• 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": "..."
}

太棒了。

然后，在访问令牌到期前大约10秒，客户端向/OAuth2/令牌发出另一个POST请求，这次使用以下参数：

• refresh_token：...
• grant_type："refresh_token“
• client_id："MyClient“

并返回以下成功的响应：

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

注意，这一次不返回刷新令牌。同样的情况还会发生四次(总共大约14分钟，那么是SSOLifetime的两倍吗？)当刷新令牌仍然有效时，最后，在第四次请求新访问令牌时，我将收到以下正文中的400错误：

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

​

​

这有点道理但是..。当当前刷新令牌接近到期时间时，不应该发出新的刷新令牌吗？

官方博士在这个问题上有点神秘：

虽然在使用刷新令牌获取新访问令牌时不会撤销刷新令牌，但您应该放弃旧的刷新令牌。根据OAuth2.0规范， 说：“授权服务器可能会发出一个新的刷新令牌，在这种情况下，客户端必须放弃旧的刷新令牌，用新的刷新令牌替换它。授权服务器在向客户端发出新的刷新令牌后，可能会撤销旧的刷新令牌。”当新的刷新令牌生存期比以前的刷新令牌生存期长时， AD FS会发出刷新令牌。若要查看有关AD FS刷新令牌生存期的其他信息，请访问AD在设置上的单个标志。

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

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

...but，那永远都是这样的，不是吗？

对于如何配置as，以便在需要时也会发出新的刷新令牌，有什么想法吗？理想情况下，拥有刷新令牌旋转会很好，但一次只做一件事.

Answer 1

通常，在OAuth中，刷新令牌的生存期是在委托时设置的，用户登录时，用户可以在指定时间内同意使用某些权限。

因此，如果用户在09:00登录8小时的会话，而他们的应用程序在10:00刷新访问令牌，那么如果发布了新的刷新令牌，则应该可以使用7小时。也就是说，如果不让用户再次参与，就不能重写初始委托。

正如您所说，新的趋势是在每次访问令牌刷新时获得一个新的刷新令牌，但这只是一种保护机制，ADFS不支持这种机制。因此，我将按以下方式进行：

• 将SSO生命周期设置为所需的值(如8小时)，并将访问令牌生存期设置为标准值(如30分钟)
• 以面向未来的方式编写代码，如果获得新的更新令牌，则放弃现有的刷新令牌。

本地应用程序中的刷新令牌

基于注释，您正在尝试使用PKCE，并且希望使用旋转刷新令牌，但是ADFS不支持后者，因此不能。

您有一个本地应用程序，标准解决方案总是将刷新令牌存储在安全操作系统存储中，仅供应用程序和用户使用。刷新令牌是否旋转不重要。示例：

• 桌面应用程序
• iOS应用程序
• Android应用

SPAs

令牌和浏览器是一个完全不同的主题，因为没有任何地方可以安全地存储刷新令牌。由于最近第三方cookie浏览器的限制，使Javascript应用程序工作的唯一方法是在本地存储中存储刷新令牌，从安全的角度来看，这是灾难性的。

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

• 代码
• 文档