使用授权类型代码时 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-client 版本 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_uri https://myspaurl/static/silent-renew.html 从未被请求过。所以我的问题是，当使用授权类型 Code 而不是旧的隐式流时 silent_redirect_uri 是否已过时？

Answer 1

如果 oidc 客户端可以获得刷新令牌，它将使用它而不是尝试使用静默重定向 URI。考虑接下来的这些操作：

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

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

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

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

安全

问题还没有结束：

绝对不建议将 RT 存储在本地存储中用于中等或高安全性应用程序 - 即使使用旋转刷新令牌也是如此

2021 年的建议是将刷新令牌存储在高度加密的 HTTP Only SameSite=strict cookie 中。这被称为 Back End for Front End 模式。

这很棘手，但值得一提 - 也许作为未来 objective。另请注意，oidc 客户端现在是一个存档项目。

使用授权类型代码时 silent_redirect_uri 是否过时

Is silent_redirect_uri obsolete when using grant type Code

refresh

identityserver4

access-token