我正在研究使用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委员会中讨论过这个问题（我相信它已经有了），以及它是否在路线图中得到解决。提前感谢您的帮助！
答案 0 :(得分：3)
您期望什么样的解决方案？
如果您使用OIDC来保护您的资源，SLO将正常工作（无论如何，您将检查访问资源时的access_token，这将被撤销），但是当OIDC用作身份提供者时则不行。
OIDC没有推送SLO。您无法通过OIDC在OP中实现可靠的SLO。
目前，每个RP都应该处理SLO，这是您提到的OIDC会话管理规范中指定的。如果RP不受你的控制，你就无法强制执行它。
答案 1 :(得分：1)
没有正式的解决方案，正如Vilmantas在他的回答中正确指出的那样：
如果RP无法控制，则无法强制执行。
无论如何，仍然有一个选项，虽然这个可能与OpenID Connect的使用相矛盾，但无论如何，我们走了：
当用户注销时，将令牌放在身份提供者的撤销列表中。然后，您需要一种机制来将此撤销列表推送（或定期提取）到所有依赖方的后端。然后，当用户尝试访问依赖方（并且他们仍然拥有其令牌）时，虽然令牌基本上仍然有效，但依赖方可以拒绝它，因为它已被同时撤销。
当然，这意味着您需要对撤销列表进行某种理想实时更新，这可能会使OpenID Connect的整个想法变得毫无用处。但这是一个选择......
答案 2 :(得分：0)
如果您的OAuth服务器发出刷新令牌，并且它实现了RFC 7009，那么您可以使用该端点撤消刷新令牌，并防止它被用于发布任何新的访问权限令牌
我们在具有长（12小时）刷新令牌和短（5分钟访问令牌）的场景中成功使用此功能。并且为了更好地衡量，OAuth服务器还会在特定时间段（30分钟）内未请求新访问令牌时将会话标记为空闲（实质上是撤销）。
答案 3 :(得分：0)
您提到了“ 一些直接的OP-> RP通讯”；这正是Back-Channel Logout机制的作用。
在OP注册的每个客户端都包括backchannel_logout_uri；当用户注销OP时，OP在每个已登录的RP上使用对此URI的http POST来告诉他们注销用户。
因为这是到客户端系统的后端的，所以即使用户没有与客户端系统的前端处于活动状态的浏览器会话，它也可以正常工作。