使用授予类型"代码"时，silent_redirect_uri是否已过时

Question

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

我使用以下配置的IdentityServer 4.1.2：

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

正如您所看到的，我不是使用不推荐使用的隐式流，而是将授予类型设置为Code

我的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开发工具的"网络"选项卡中，我可以看到访问令牌正在使用此请求url进行更新https://myidentityserver/connect/token.我的silent_redirect_urihttps://myspaurl/static/silent-renew.html从未被请求。因此，我的问题是，当使用授予类型Code而不是旧的隐式流时，silent_redirect_uri是否已过时？

Answer 1

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

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

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

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

请注意，在隐藏或框架上使用静默重定向URI在Safari浏览器中不起作用，因为它会丢弃第三方cookie。预计其他浏览器也会效仿。因此，在2021年，在隐藏的iframe上续订代币确实受到了反对。

安全

问题还没有结束：

• 对于中等或高安全性的应用程序，绝对不建议将RT存储在本地存储中，即使使用了循环刷新令牌

2021年的建议是将刷新令牌存储在一个强加密的HTTP Only SameSite=strict cookie中。这就是所谓的"后端换前端"模式。

这很棘手，但值得注意——也许是作为未来的目标。还要注意，oidc客户端现在是一个归档项目。