Asp.net IdentityServer4后台通道注销问题

在ASP.NET Core 2上使用IdentityServer 4。 使用ASP.NET MVC5与此用例相关的两个客户端

编辑：使用cookies进行身份验证，隐式流

像这样使用后台通道注销：
*涉及4个应用程序—两个客户端（我们称它们为客户端A和客户端B）、IdentityServer实例和一个状态服务器，用于跟踪后台通道注销请求

客户端A启动注销，使登录cookie无效

客户端使用正确的id_令牌将用户重定向到IdentityServer的/帐户/注销

IdentityServer使登录cookie无效，并为所有已登录客户端回调通道注销操作

客户端B的后通道注销操作验证请求并将注销请求通知状态服务器

当向客户机B发出下一个请求时，该客户机查询状态服务器并获取有关未完成注销请求的信息，从而使注销cookie无效，从而导致成功注销

状态服务器跟踪两个参数：

sub

和

sid

来自id\u令牌的声明

我有以下问题：

当用户登录到客户机a，然后导航到客户机B，然后在那里执行注销时，客户机B将注销，但客户机a直到向其发出下一个请求。因此，如果用户现在决定使用另一个（或相同的，无所谓）帐户登录到客户端B，然后导航到客户端A，客户端A将启动注销，因为状态服务器上有一个未完成的注销请求，而不考虑用户在此期间再次登录的事实

---

有人知道如何防止这种情况吗？

按照您的场景，当您的客户端A执行“延迟注销”时，我看不出有任何问题，该“延迟注销”会触发对IdSrv的新挑战，并以新令牌和新cookie结束。
重点不应该是在每个特定的“延迟注销”上触发（循环）单一注销.

为什么这么复杂？将IdSrv4与不透明令牌（也称为引用令牌）一起使用并减少（或者如果是低流量场景：禁用）缓存时间不是更容易吗？根据请求，服务将要求IdSrv查看令牌是否有效？@Tseng吊销端点仅用于访问和刷新令牌。我对隐式流使用cookies身份验证。为什么对隐式流使用反向通道？看起来有点奇怪。如果您使用cookie，那么对于所有涉及的客户端，使用前端通道和撤销iFrame中的cookie应该更简单。这取决于您如何利用前端和后端，但IdSrv中的afaik后端实现仍然依赖于注销视图中的iFrame，因此它没有（再次）隐式流的特殊支撑。总之，仅根据您的场景，当您的客户端A执行“延迟注销”从而触发对IdSrv的新挑战时，我看不到任何问题，以一个新令牌和一个新cookie结束。主要的一点不应该是在每个特定的“延迟注销”上触发（循环）单一注销。客户总是对的吗？也许，也许：）不管怎样，我很乐意帮忙！：）谢谢，执行挑战是关键。这是有道理的，实际上，不知道为什么我触发了一个新的注销懒惰注销。如果客户端确实已注销，则质询将显示登录页面，如果客户端同时已登录，则质询将选择新的令牌和cookie。