【发布时间】:2014-12-30 08:20:05
【问题描述】:
我们刚刚讨论了使用 OAuth 2 时的登录和注销行为。假设我们有两个 Web 应用程序 A 和 B 使用一个 OAuth 提供程序 O(使用 spring-security-oauth2 堆栈构建)。
当您想登录A 时,您会被重定向到O,输入您的凭据,在O 上获得一个会话,使用访问令牌重定向回A,并在@ 上创建一个会话987654330@也一样。
现在,当您想登录 B 时,您会被重定向到 O,并直接将令牌发送回 B,因为您在 O 上仍然有一个有效的 sesison,并且在 B 上创建了一个会话以及(无需再次输入您的凭据)。
这解决了我们的单点登录问题。
现在的一个要求是,当您从A 或 B 注销时,您始终会从两个/所有应用程序中注销(单次注销)。
我们的想法是:
- 使用当前会话 id 增强访问令牌
- 如果应用程序
A或B想要注销用户,它们会将他重定向到O的注销页面 - 如果用户从
O注销,属于O上当前会话的所有访问令牌都将被删除,用户将被重定向回A或B -
A或B上的会话被破坏 -
A和B在每个请求上检查他们的 OAuth 访问令牌的有效性,如果令牌不再有效,则销毁他们的会话
您认为这是 OAuth 2 的有效用例吗?您将如何以不同的方式实施单点注销?
【问题讨论】:
-
OpenID 最近添加了两个处理单点注销的新规范:openid.net/specs/openid-connect-logout-1_0.html 和 openid.net/specs/openid-connect-backchannel-1_0.html 这些比 OpenID 连接的会话管理方法更容易处理。
-
嗨,James,我们有类似的要求,希望收到您的来信。您是采用这种方法还是找到其他更好的解决方案?
-
由于我们目前在同一个域上运行所有应用程序,我们现在使用共享 cookie 来共享会话并处理单点注销。 OAuth 提供者还具有 /end_session 端点,应用程序可以调用该端点以进行正确的注销。为了防止 CSRF 攻击,end_session 端点需要一个有效的签名 JWT 令牌作为查询参数传递。
标签: oauth oauth-2.0 logout spring-security-oauth2