IdentityServer4 反向通道注销问题答案

【问题标题】：IdentityServer4 back-channel logout problemIdentityServer4 反向通道注销问题
【发布时间】：2019-02-08 06:20:20
【问题描述】：

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

编辑：使用 cookie 进行身份验证，隐式流程。

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

客户端 A 启动注销，使登录 cookie 无效。
客户端用户使用正确的 id_token 被重定向到 IdentityServer 的 /account/logout。
IdentityServer 使登录 cookie 无效并为所有登录的客户端调用反向通道注销操作。
客户端 B 的反向通道注销操作验证请求并将注销请求通知状态服务器。
当向客户端 B 发出下一个请求时，该客户端会查询状态服务器并获取有关未完成的注销请求的信息，这会导致它使注销 cookie 无效，从而导致成功注销。李>

状态服务器跟踪两个参数：sub 和 sid 来自 id_token 的声明。

我遇到以下问题：

当用户登录到客户端 A，然后导航到客户端 B，然后在那里执行注销时，客户端 B 将退出，但客户端 A 直到下一次向它发出请求时才会退出。因此，如果用户现在决定使用另一个（或相同的，无关紧要的）帐户登录到客户端 B，然后才导航到客户端 A，客户端 A 将启动注销，因为有一个未完成的注销请求正在等待状态服务器，忽略用户在此期间再次登录的事实。

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

【问题讨论】：

为什么这么复杂？将 IdSrv4 与不透明令牌（又名参考令牌）一起使用并减少（或者如果它是低流量场景：禁用）缓存时间会不会容易得多？收到请求后，服务会询问 IdSrv 的 revocation endpoint 以查看令牌是否有效？
@Tseng 撤销端点仅用于访问和刷新令牌。我使用带有隐式流程的 cookie 身份验证。
为什么要使用带有隐式流的反向通道？看起来有点奇怪。如果您使用 cookie，则使用前端通道并为所有涉及的客户端撤销 iframe 中的 cookie 应该更简单。这取决于您是否可以同时使用前向和后向，但在 IdSrv 中的后向实现仍然依赖于注销视图中的 iframe，因此它没有（再次）隐式流的特殊道具。
无论如何，只要按照您的方案，当您的客户端 A 执行“延迟注销”触发对 IdSrv 的新挑战，以新令牌和新 cookie 结束时，我看不到任何问题。重点不应该是在每个特定的“惰性注销”上触发（循环）单点注销。
客户永远是对的？也许，也许 :) 很高兴能提供帮助！ :)

标签： asp.net authentication asp.net-core identityserver4 openid-connect

【解决方案1】：

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

【讨论】：

谢谢，完成挑战是关键。这实际上是有道理的，不知道为什么我在延迟注销时触发了新的注销。如果客户端真的退出，挑战会显示登录页面，如果客户端同时登录，它将选择一个新的令牌和 cookie。