OpenID Connect - 如何处理单点注销

18

我正在调查将OpenID Connect作为我们企业应用程序(面向消费者)的SSO协议的使用情况。总体而言,它的大部分方面都符合我们的需求,但它处理单点注销的能力令人担忧,希望能得到一些指导。

我已经有机会查看了最新的OIDC会话管理规范,以及几个与类似主题相关的Stack Overflow问题:

正如Ping公司的人所提到的,单点注销与SAML2不同,更加以用户为中心。这很好,但仍然感觉不符合实际单点注销的需求。具体来说,通过有些笨拙的iframe通信进行的用户中心处理只适用于当前浏览器视图,但不适用于当前未被查看的RP。
例如,用户使用特定OP登录RPs A、B和C。单点注销只会触发浏览器正在查看的那些RPs的注销;这将使得其他会话继续存在,可能会带来安全问题。(如果我分析错误,请纠正我。)

我已经看到一些在协议之外工作的解决方案(例如父域cookie,或者可能是相同的会话存储),但不幸的是它们不符合我的需求。

我正在尝试看看OIDC规范是否遗漏了某些内容,建议包括类似于SAML2自身单点注销的用例的单点注销协议?(也许是一些直接的OP->RP通信?甚至是客户端的“迭代通过RP”注销?)。还是我真的要自己开发专有解决方案?

顺便问一下,这个问题是否在OIDC委员会中讨论过(我相信已经讨论过),以及是否在路线图上得到了解决。

提前感谢您的帮助!


你是否曾经确定了特定的实现方式? - Brad Parks
4个回答

3

你期望的是什么样的解决方案?

如果您使用OIDC来保护您的资源(您将在访问资源时检查access_token,该访问将被撤消),则SLO将很好地工作,但在OIDC用作身份提供者的情况下,则不适用。

OIDC没有push-SLO。 您无法通过OIDC的手段实现可靠的SLO。

目前,每个RP都应该负责SLO,这在您提到的OIDC Session Management规范中有所说明。 如果RPs不受您控制,则无法强制执行它。


2
不再完全正确了!请参考Vince关于OpenID Connect反向通道注销的回答。 - Martin Cejp

3
您提到了“一些直接的OP->RP通信”,这正是Back-Channel Logout机制所做的事情。
在OP注册的每个客户端中都包括backchannel_logout_uri;当用户退出OP时,OP会使用http POST发送到每个已登录的RP的此URI,告诉它们注销用户。
因为这是发送到客户端系统的后端,即使用户没有与客户端系统的前端建立浏览器会话,它也可以工作。

1

目前没有官方解决方案,正如 Vilmantas 在他的回答中正确指出的那样:

如果 RP 不在你的控制范围内,你就无法进行强制执行。

不过,仍然有一个选项,尽管这可能与使用 OpenID Connect 相矛盾,但是我们来看看:

使用令牌吊销列表。

当用户退出登录时,请将令牌放在身份提供者的吊销列表上。然后,您需要一种机制将此吊销列表推送(或定期拉取)到所有依赖方的后端。然后,当用户尝试访问依赖方(并且他们仍然拥有其令牌)时,尽管令牌基本上仍然有效,依赖方也可以因为其在此期间被吊销而拒绝它。

当然,这意味着您需要某种理想情况下实时更新吊销列表的方式,这可能会使整个 OpenID Connect 的想法变得毫无用处。但这是一个选项...


0
如果您的OAuth服务器发出刷新令牌,并且实现了RFC 7009,那么您可以使用该端点撤销刷新令牌,并防止其用于发出任何新的访问令牌。
我们在长(12小时)刷新令牌和短(5分钟访问令牌)的情况下成功地使用了这个方案。为了保险起见,当一定时间内(30分钟)没有请求新的访问令牌时,OAuth服务器还会将会话标记为空闲状态(本质上是撤销)。

出于好奇,您撤销空闲会话的“良好措施”是否在30分钟后抵消了具有12小时生命周期的刷新令牌的意义 - 因为在30分钟后它们将变得无用?还是我理解错了?代朋友问一下...谢谢。 - Andy Lorenz
@AndyLorenz 请求访问令牌会推动30分钟的滚动窗口。因此,如果您将运行应用程序的计算机休眠,并且在30分钟内不刷新,则会话结束。否则,如果您是活跃用户,则最多可以将30分钟的窗口向前滚动12小时。 - Bart Verkoeijen

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接