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

时间:2013-10-15 02:55:42

标签: session oauth oauth-2.0 openid single-sign-on

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

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

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

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

两种方法的优点和缺点是什么?您可能采取其他方法吗?是否存在安全风险?并发性和可伸缩性考虑因素?请帮忙!

1 个答案:

答案 0 :(得分:0)

我会采用不同的oauth路线。

  1. Oauth
  2. 我更喜欢的方法是 - 在设备级别(User-Application / Device)发出的访问令牌。 即,将有一个注册您的设备并授予其访问权限的过程。 这将导致生成特定于设备的访问令牌并根据具体情况存储在设备中。 (例如: - 对于移动设备,您可能需要更长的到期访问令牌和网页更短的持续时间)。 这样,您就可以跨设备分离登录/注销。

    然而,这种方法的结论是:

    1. 更复杂的实施,因为它涉及设备注册
    2. 由于您有两个或更多与用户关联的访问令牌,因此跟踪每个用户的操作将非常困难。
    3. 优点:

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

      1. 基于会话的SSO管理
      2. 优点:

        • 比OAuth更简单

        缺点:

        • 围绕-session / cookie处理的安全限制
        • 稍后可扩展性以增加更多用例是有限的