使用 oAuth2 或共享会话单点登录

and*_*der 5 openid session oauth single-sign-on oauth-2.0

我有三个面向客户端的 Web 应用程序,它们都位于不同的子域上(其中一个 Web 应用程序实际上有 700 多个不同的子域,而且这些子域一直在变化)。我已经编写了一个 oAuth 服务器,我将使用它来允许用户登录到每个系统;这是可行的,但是我开始遇到正在发生的事情和我在编写注销代码时希望的实际行为之间的差异。

我对单点登录的一些要求是:

  • 如果在一个系统上登录,您就会在所有系统上登录(显然)。
  • 如果退出一个系统,您就会退出所有系统。甚至跨子域。
  • 例如,如果您在两台不同的计算机上登录,例如手机和台式机。在手机上注销时,请勿在桌面上注销。

我们已经编写了 oAuth 提供程序,并且将其用于未耦合到我们的域(API 等)的项目,但我并不完全相信 oAuth 是满足上述要求的最佳解决方案。我想也许共享会议会更好。共享会话的想法将涉及存储在主域上的 cookie,其中包含有关当前登录用户的信息。

这两种方法的优点和缺点是什么?您还可以采取其他方法吗?是否存在需要考虑的安全风险?并发性和可扩展性考虑因素?请帮忙!

ran*_*ess 0

我会采取有差异的 oauth 路线。

  1. 授权

我更喜欢的方法是 - 在设备级别(用户应用程序/设备)颁发访问令牌。即,将有一个注册您的设备并授予其访问权限的过程。这将导致生成特定于设备的访问令牌并根据情况存储在其中。(例如:- 对于移动设备,您可能需要较长有效期的访问令牌,而网页则需要较短期限的访问令牌)。这样您就可以解耦跨设备的登录/注销。

然而这种方法的缺点是:

  1. 实现更复杂,因为它涉及设备注册
  2. 跟踪每个用户的操作将很困难,因为您有两个或多个与用户绑定的访问令牌。

优点:

  • 这是一个相当标准的方式
  • 缺点 2 可以解决(添加访问令牌属性等)。

  1. 基于会话的 SSO 管理

优点:

  • 比 OAuth 更简单

缺点:

  • 围绕会话/cookie 处理的安全限制
  • 稍后添加更多用例的可扩展性是有限的