17

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

我有机会查看了最新的 OIDC 会话管理规范，以及涉及类似主题的几个堆栈溢出问题：

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

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

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

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

在此先感谢您的帮助！

4

4 回答 4

3

你期待什么样的解决方案？

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

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

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

于 2015-11-30T15:55:36.593 回答
2

您提到了“一些直接的 OP->RP 通信”；这正是反向通道注销机制所做的。

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

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

于 2018-09-12T14:37:16.573 回答
1

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

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

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

使用令牌撤销列表。

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

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

于 2017-03-01T09:54:55.143 回答
0

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

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

于 2018-02-13T03:53:27.117 回答