当使用授予类型代码时，silent_redirect_uri是否过时？

Question

我有一个关于刷新访问令牌的问题。

我使用的是IdentityServer 4.1.2，配置如下：

new Client
{
  ClientId = "myid",
  AllowedGrantTypes = GrantTypes.Code,
  RequireClientSecret = false,
  AccessTokenLifetime = 3600,
  RequirePkce = true,
  AllowOfflineAccess = true,
  ...
}

如您所见，我是而不是，使用的是不推荐的隐式流，但是授予类型被设置为代码

我的SPA客户端使用的是oidc版本1.11.5，配置如下：

var config = {
    ...
    redirect_uri: `https://myspaurl/callback`,
    response_type: 'code',
    scope: 'openid profile offline_access',
    automaticSilentRenew: true,
    silent_redirect_uri: `https://myspaurl/static/silent-renew.html`,
    ...
  };

请注意，我请求的是offline_access作用域，因此我可以获得一个刷新令牌。

当我运行应用程序时，访问令牌每小时更新一次。在Chrome工具中的Network中，我可以看到访问令牌正在使用这个请求url https://myidentityserver/connect/token进行更新。我的silent_redirect_uri https://myspaurl/static/silent-renew.html从未被请求过。因此，我的问题是，当使用授予类型的silent_redirect_uri代码而不是旧的隐式流时，是否已经过时？

Answer 1

如果oidc客户端可以获得刷新令牌，它将使用该令牌，而不是尝试使用无声的重定向URI。下面考虑这些行动：

• 用户重新加载页面
• 用户打开新的浏览器选项卡/窗口

如果RT在重新加载期间不可用，那么oidc客户端将返回到无声的重定向URI行为。

多选项卡浏览可以使用刷新令牌的唯一方法是在本地存储中存储RT (一个长期存在的凭据)。然后，您将有一个可靠的应用程序。

请注意，在隐藏或帧上使用静默重定向URI在Safari浏览器中不起作用，因为它将删除第三方cookie。预计其他浏览器也会效仿。因此，在隐藏的iframe上更新令牌确实在2021年被废弃了。

安全

不过，问题并没有结束：

• 对于中等或高安全的应用程序，绝对不建议在本地存储RT --即使使用旋转刷新令牌。

2021年的建议是将刷新令牌存储在一个强加密的HTTP SameSite=strict cookie中。这被称为前端后端模式。

这是一个棘手的问题，但值得注意--也许这是未来的目标。还请注意，oidc客户端现在是一个存档的项目。