IdentityServer4后端注销问题

Question

在ASP.NET Core 2上使用IdentityServer4，有两个与此用例相关的客户端，使用ASP.NET MVC5。
编辑：使用cookie进行身份验证，隐式流程。
使用如下的后端信道注销：
* 有4个应用程序涉及其中——两个客户端（称为客户端A和客户端B）、IdentityServer实例以及一个状态服务器来跟踪后端信道注销请求。

1. 客户端A开始注销，使登录cookie无效。
2. 客户端A用户被重定向到IdentityServer的/account/logout，并带有正确的id_token。
3. IdentityServer使登录cookie无效并调用所有已签入客户端的后端信道注销操作。
4. 客户端B的后端信道注销操作验证请求并通知状态服务器注销请求。
5. 当发出向客户端B的下一个请求时，该客户端查询状态服务器并获取有关未处理注销请求的信息，这导致它使注销cookie无效，从而成功地注销登录。

状态服务器跟踪id_token中的两个参数：sub和sid声明。
我遇到了以下问题:
当用户登录到客户端A，然后转到客户端B，然后在那里执行注销操作时，客户端B被注销，但是直到下一个针对客户端A的请求被发出后，客户端A才被注销。因此，如果用户现在决定使用另一个账户（或相同的账户，无论如何），然后只转到客户端A，客户端A将发起注销，因为状态服务器上有一个未处理的注销请求，而忽略了用户在此期间重新登录的事实。
有没有人有什么想法可以防止这种情况发生？

- Dejan Janjušević

---

为什么这么复杂？使用 IdSrv4 和不透明令牌（也称引用令牌）不是更容易吗？只需减少（或如果是低流量场景：禁用）缓存时间。在请求时，服务将询问 IdSrv 的撤销端点以查看令牌是否有效？ - Tseng

@Tseng 撤销终端点仅用于访问和刷新令牌。我使用隐式流程的 cookie 认证。 - Dejan Janjušević

为什么要在隐式流中使用后端通道？这看起来有点奇怪。如果您使用Cookies，那么使用前端通道并在所有涉及的客户端的iframe中撤销Cookies应该更简单。您可以同时利用前端和后端通道，但据我所知，IdSrv中的后端实现仍然依赖于注销视图中的iframes，因此它对（再次）隐式流没有特殊的属性。 - d_f

@d_f 我想使用前端通道注销，但我遇到了这样一种情况：客户端在https上托管IdentityServer，而其中一些客户端在http上。不允许从安全网页创建指向不安全网页的iframe，这就是为什么我决定使用后端通道方法（顾客永远是对的，不是吗？）。你的第二条评论听起来不错，我确实会触发循环单点注销，而不仅仅是在懒散注销时执行挑战。你能把它发布为答案吗？听起来很好。 - Dejan Janjušević

客户永远是对的？也许吧，也许不是 :) 无论如何，很高兴能帮忙！: ) - d_f

Answer 1

根据您的情景，当客户端A执行“懒惰退出”并触发新的IdSrv挑战时，我看不到任何问题，最终得到新的令牌和新的cookie。
主要问题在于不要在每个特定的“懒惰退出”上触发（循环）单点退出。

- d_f

---

谢谢，完成挑战是关键。实际上很有道理，不确定为什么我在懒惰退出时触发了新的注销。如果客户端真正注销，挑战将显示登录页面，并且如果客户端在此期间已经登录，则会选择新的令牌和cookie。 - Dejan Janjušević