session - 使用 oAuth2 或共享 session 单点登录

Question

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

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

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

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

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

Answer 1

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

1. 认证:

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

但是这种方法的缺点是:

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

优点:

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

<小时/>

基于 session 的 SSO 管理

优点:

• 比 OAuth 简单

缺点:

• 有关 session /cookie 处理的安全限制
• 以后添加更多用例的可扩展性有限