我正在研究使用OpenID connect作为我们的企业应用程序（面向消费者）的SSO协议。一般来说，它的大多数方面都符合我们的需求，除了它处理单一注销的能力，并希望得到一些指导。
我有机会回顾latest OIDC session management spec，以及触及类似主题的几个堆栈溢出问题：
正如ping所提到的那样，单个注销的处理方式与SAML2不同，因为它更加以用户为中心。这一切都很好，但它仍然不适合实际单点注销的需要。具体来说，以用户为中心的处理（通过有点kludgy iframe通信）仅适用于当前浏览器视图，但不适用于当前未被查看的RP。 例如，用户使用特定的OP登录RP A，B和C.单点注销只会触发浏览器正在查看的RP的注销;这将使其他会话挥之不去，这可能是一个安全问题。 （如果我错误地分析了这个，请更正）。
我已经看到一些在协议之外工作的解决方案（例如父域cookie，或者可能（??）同一个会话存储）但遗憾的是那些不适合我的需求。
我试图看看我是否可能错过了有关OIDC规范的内容，该规范建议单一注销协议覆盖类似于SAML2自己的单一注销的用例？ （可能是某些直接OP-> RP通信？甚至是客户端“迭代直通RP”注销？）。或者我真的离开了自己为它开发专有解决方案？
BTW，也很好奇是否已经在OIDC委员会讨论过这个问题（我相信它已经有了），以及它是否在路线图中得到解决。
在此先感谢您的帮助！
你期望什么样的解决方案？
如果您使用OIDC来保护资源，SLO将正常工作（无论如何，您将检查访问资源时的access_token，这将被撤销），但是当OIDC用作身份提供者时则不行。
OIDC没有推送SLO。您无法通过OIDC在OP中实现可靠的SLO。
目前，每个RP都应该处理SLO，这是您提到的OIDC会话管理规范中指定的。如果RP不受你的控制，你就无法强制执行它。
没有正式的解决方案，正如Vilmantas在他的回答中正确指出的那样：
如果RP不受你的控制，你就无法强制执行它。
无论如何，仍然有一个选项，虽然这可能与OpenID Connect的使用相矛盾，但无论如何，我们在这里：
当用户注销时，将令牌放在身份提供者的撤销列表中。然后，您需要一种机制来将此撤销列表推送（或定期提取）到所有依赖方的后端。然后，当用户尝试访问依赖方（并且他们仍然拥有其令牌）时，虽然令牌基本上仍然有效，但是依赖方可以拒绝它，因为它同时被撤销了。
当然，这意味着您需要对撤销列表进行某种理想的实时更新，这可能会使OpenID Connect的整个想法变得毫无用处。但这是一个选择......
如果您的OAuth服务器发出刷新令牌，并且它实现了RFC 7009，那么您可以使用该端点撤消刷新令牌，并防止它被用于发出任何新的访问令牌。
我们在具有长（12小时）刷新令牌和短（5分钟访问令牌）的场景中成功使用此功能。并且为了更好地衡量，当在一定时间段（30分钟）内没有请求新的访问令牌时，OAuth服务器还将会话标记为空闲（实质上是撤销）。
你提到'一些直接OP-> RP通信';这正是Back-Channel Logout机制所做的。
在OP注册的每个客户包括backchannel_logout_uri;当用户退出OP时，OP在每个登录的RP中使用http POST到此URI，告诉他们将用户注销。
因为这会进入客户端系统的后端，即使用户没有与客户端系统的前端活动的浏览器会话，它也会起作用。