OpenID Connect - 如何处理单次注销

Posted 2023-02-25

【中文标题】OpenID Connect - 如何处理单次注销

【英文标题】：OpenID Connect - how to handle single logout

【发布时间】：2015-01-09 14:41:51

【问题描述】：

我正在调查将 OpenID 连接用作我们的企业应用程序（面向消费者）的 SSO 协议。总的来说，它的大部分方面都符合我们的需求，除了它能够处理单次注销并希望对此提供一些指导。

我有机会查看latest OIDC session management spec，以及涉及类似主题的几个堆栈溢出问题：

OpenID Connect will eventually replace saml... single sign off using oauth2

正如 ping 的人所说，单次注销的处理方式与 SAML2 不同，因为它更以用户为中心。这一切都很好，但仍然感觉不适合实际单次注销的需求。具体来说，以用户为中心的处理（通过有点笨拙的 iframe 通信）仅适用于当前浏览器视图，但不适用于当前未查看的 RP。 例如，用户使用特定的 OP 登录到 RP A、B 和 C。单次注销只会触发浏览器正在查看的那些 RP 的注销；这将使其他会话挥之不去，这可能是一个安全问题。 （如果我对此分析有误，请更正）。

我看到了一些在协议之外工作的解决方案（例如父域 cookie，或者可能 (??) 相同的会话存储），但很遗憾，这些解决方案不符合我的需求。

我想看看我是否遗漏了有关 OIDC 规范的一些内容，该规范建议使用单一注销协议，涵盖类似于 SAML2 自己的单一注销的用例？ （也许是一些直接的 OP-> RP 通信？甚至是客户端“通过 RP 迭代”注销？）。还是我真的要靠自己为它开发专有解决方案？

顺便说一句，我也很想知道 OIDC 委员会是否已经讨论过这个问题（我确定已经讨论过），以及它是否在要解决的路线图上。

提前感谢您的帮助！

【问题讨论】：

你有没有接触过特定的实现？

【参考方案1】：

您期望什么样的解决方案？

如果您使用 OIDC 保护您的资源，SLO 可以正常工作（无论如何，您将检查 access_token 对资源的访问，这将被撤销）但在 OIDC 用作身份提供者的情况下则不然。

OIDC 没有推送 SLO。您无法通过 OIDC 在 OP 内实现可靠的 SLO。

目前每个 RP 都应该处理 SLO，这是在您提到的 OIDC 会话管理规范中指定的。如果 RP 超出您的控制范围，您将无法强制执行。

【讨论】：

不完全正确了！请参阅 Vince 关于 OpenID Connect Back-Channel Logout 的回答。

【参考方案2】：

你提到了'一些直接的 OP->RP 通信'；这正是Back-Channel Logout 机制的作用。

在 OP 注册的每个客户端都包含 backchannel_logout_uri；当用户从 OP 注销时，OP 在每个登录的 RP 上使用一个 http POST 到这个 URI 来告诉他们注销用户。

因为这会转到客户端系统的后端，所以即使用户没有与客户端系统的前端活动的浏览器会话，它也可以工作。

【参考方案3】：

对此没有官方解决方案，正如 Vilmantas 在他的回答中正确指出的那样：

如果 RP 超出您的控制范围，您将无法强制执行。

无论如何，还有一个选项，虽然这可能与使用 OpenID Connect 相矛盾，但无论如何，我们开始吧：

使用令牌撤销列表。

当用户注销时，将令牌放在身份提供者的撤销列表中。然后，您需要一种机制来将此撤销列表推送（或定期拉取）到所有依赖方的后端。然后，当用户尝试访问依赖方（并且他们仍然有自己的令牌）时，虽然令牌基本上仍然有效，但依赖方可以拒绝它，因为它同时被撤销了。

当然，这意味着您需要对撤销列表进行某种理想的实时更新，这可能会使 OpenID Connect 的整个想法变得毫无用处。但这是一种选择……

【参考方案4】：

如果您的 OAuth 服务器发出刷新令牌，并且它实现了RFC 7009，那么您可以使用该端点撤销刷新令牌，并防止它被用于发出任何新的访问令牌。

我们在具有长（12 小时）刷新令牌和短（5 分钟访问令牌）的场景中成功使用了此功能。而且，当在特定时间段（30 分钟）内没有请求新的访问令牌时，OAuth 服务器也会将会话标记为空闲（本质上是撤销）。