oauth-2.0 - 基于 OAuth2 的 SSO

Question

我们的项目包含几个子应用程序，我们正在寻找一种实现 SSO 的解决方案，以避免对每个子应用程序进行身份验证。
假设这是我们项目的结构:

authentication server(call it AS or IdP or something else)
order-system
product-system
data-analysis-system
.......

而且我们发现有很多“基于OAuth2实现SSO”的文章如 this .
在那篇文章中，我们更喜欢 SAML策略，因为它简单明了，但是对于原生应用程序有一些限制，所以我们专注于 OAuth2。
这是工作流程:

1 OAuth2 中的规则

Resource Server (SP) – this is the web-server you are trying to accessinformation on.

Client – this is how the user is interacting with the Resource Server.This could be a browser-based web app, a native mobile app, a desktopapp, a server-side app.

Authorization Server (Idp) – this is the server that owns the useridentities and credentials. It's who the user actually authenticatesand authorizes with.

拍 OctoDroid 例如，规则非常明确:

Client: OctoDroid
Idp: GitHub
SP: Github
User: one who use OctoDroid application.

工作流程是 OctoDroid( Client) 要求你( User) 通过 Github( Idp) 登录并授予权限，以从 Github( SP) 获取资源(repos,issues)。
但是在我们的应用程序中，每个子系统究竟可以处理什么？一个 SP或 Client ?
如果被视为 SP , 是网络浏览器 Client ?我一直以为 Client应该是一个应用程序。并且子系统对每个请求都通过Idp验证access_token，然后返回相关资源，这样会不会增加Idp的压力？
如果被视为 Client ，谁是 SP ?
2 应用规则
对于同一个用户，他在不同的子系统中可能有不同的规则，比如他可以读/写 order-system的所有订单。 ，但他无法访问 product-system .那么规则配置应该发生在哪里呢？在 Idp 中还是在每个子系统中？
3 session 同步
对于一个典型的 SSO 系统，当用户登录(通过 Idp)时，所有子系统都应该登录，当用户注销时，所有子系统都应该注销。
然而在上述 OAuth2 工作流程中，似乎不同 SP s 或 Client s 是独立的。当您从 OctoDroid 注销时，您仍然可以使用 OpenHub一旦你登录。在这种情况下，OAuth2 似乎与 SSO 不同，它们如何协同工作？
4 Idp 连接到另一个 Idp
在我们的应用程序中，除了基本的用户名和密码登录之外，身份验证服务器还应提供来自 google、facebook 和其他 CAS 提供商的登录。这可能吗？

顺便说一句，我不确定我是否已经足够清楚，如果没有，请在评论中问我。

Answer 1

以为我会加入讨论，并提供一些关于最有效的模式的真实世界反馈。许多 OAuth 行话没有帮助，而且使人们感到困惑。马克·卡文杜(Mark Kavindu)作为公认的答案......
Q1。子系统
软件生产公司通常希望构建一个 UI 和 API 平台。大多数时候，用您的术语来说，UI 是客户端(它们获取 token )，而 API 是子系统(它们接收 token )。有一些异常(exception)，例如后端客户端，但这些往往是次要的。
SAML 是服务器端 Web 应用程序使用的一项旧技术，并且仍用于联合登录。如今，大多数公司都希望构建移动应用程序和基于 Javascript 的应用程序，正如 Kavindu 所说，OAuth 2.x 和 Open Id Connect 更适合这些应用程序 - 与许多库一起使用。
Q2。规则
这里的一种选择是在授权服务器中管理规则。例如，您可以将 OAuth 自定义范围用作高级权限，然后将其添加到访问 token 并由 API 读取:

订单范围意味着您可以执行订单相关操作

产品 + 写入范围意味着您可以更新产品系统

这对于简单的应用程序可能很好。对于更复杂的应用程序，它不能很好地扩展，并且存在订单 API 的范围/声明开始对产品 API 产生不利影响的风险。
更复杂的规则属于您的 API，它们随着时间的推移更易于管理。这通常涉及从子系统自己的数据中的访问 token 中查找用户。
我个人的偏好是使用基于声明的架构来最好地执行规则。如果对这种方法感兴趣，请参阅下面的我的博客文章:

User Data Management

API Claims Based Authorization

Q3。 session 同步
有时这是一个基于 OAuth 的系统无法按照利益相关者期望的方式运行的领域，人们只需要了解该技术的局限性即可。最终用户不会关心单次注销是否有效，并且您不会通过安全审查。
例如，在移动设备上，退出浏览器 UI 不会让您退出移动 UI。移动 UI 将继续使用短暂的访问 token ，但当访问 token 到期时(可能是 30 分钟后)，用户将被提示再次登录。
Q4。联邦
大多数授权服务器可以联合到多个身份提供者以支持多种类型的登录。在企业界，这通常使用 SAML 2.0 作为协议(protocol)。您允许哪些提供程序通常取决于您的子系统处理的 Assets 类型:

对于公司 Assets ，您不允许用户使用其 Facebook 帐户

登录

对于个人 Assets ，这可能没问题

在授权服务器中处理多个身份提供者通常是一个很好的技术目标。然后，您的 UI 和 API 只需与授权服务器及其 token 交互，从而降低了复杂性。