基于OAuth2的SSO

Question

我们的项目由几个子应用程序组成，我们正在寻找实现SSO的解决方案，以避免每个子应用程序的身份验证。

假设这是我们项目的结构：

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

我们发现有很多关于“基于OAuth2实现SSO”的文章都是这样的。

在那篇文章中，我们更喜欢SAML策略，因为它简单明了，但是本机应用程序有一些限制，然后我们专注于OAuth2。

这是工作流程：

1 OAuth2中的规则

资源服务器（SP）-这是您尝试访问信息的Web服务器。

客户端–这是用户与资源服务器交互的方式。这可能是基于浏览器的web应用程序、本机移动应用程序、桌面应用程序和服务器端应用程序。

授权服务器（Idp）–这是拥有用户身份和凭据的服务器。它是用户实际验证和授权的对象。

以OctoDroid为例，规则非常明确：

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

工作流是OctoDroid（客户端）要求您（用户）登录并通过Github（Idp）授予权限，以从Github（SP）获取资源（回购、发行）。

但在我们的应用程序中，每个子系统究竟可以处理什么？是SP还是客户端？

如果将web浏览器视为SP，那么它是客户端吗？我一直认为客户端应该是一个应用程序。此外，子系统还通过Idp验证每个请求的access\u令牌，然后返回相关资源，这会增加Idp的压力吗？

如果被视为客户，谁是SP？

2应用中的规则

对于同一个用户，他可能在不同的子系统中有不同的规则，例如，他可以从order-system读取/写入所有订单，但他不能访问product-system。那么规则配置应该发生在哪里？在Idp中还是在每个子系统中？

3会话同步

对于典型的SSO系统，当用户登录（通过Idp）时，所有子系统都应该登录，当用户注销时，所有子系统都应该注销。

然而，在上述OAuth2工作流中，不同的SP或客户端似乎是独立的。当您从OctoDroid注销时，登录后仍然可以使用OpenHub。在这种情况下，OAuth2似乎与SSO不同，它们如何协同工作？

4个Idp连接到另一个Idp

在我们的应用程序中，除了基本的用户名和密码登录外，身份验证服务器还应提供来自google、facebook和其他CAS提供商的登录。这可能吗？

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




Answer 1

你有很多问题。

• 但是在我们的应用程序中，每个子系统到底可以处理什么？SP还是Client？
• 如果被视为SP，Web浏览器是客户端吗？
• 如果被视为客户，SP是谁？

我认为这些问题与：OAuth 2.0四个角色有关

Oauth2角色

让我们从这个经典流程图开始：

您可以使用这些规则来确定应用程序的角色：

>

客户端

• Moderns web（react、angular、vue、linkstart等）和移动应用程序（android/ios）。一般来说，任何需要来自另一个软件的数据的软件都可以是客户端。通常，客户端是一个web，请求的数据是http api rest，但这一概念可能适用于传统（服务器渲染应用程序）或未来的应用程序（商场中的机器人）

资源服务器

• Http Rest Api。保持简单！！我们讨论的是用Postman、Soapui、curl、javascript等后台语言（java、python、nodejs等）开发的api

授权服务器

• 负责代币生成的应用程序以及与应用程序安全相关的更多功能

• 那么规则配置应该在哪里进行呢？在Idp或每个子系统中

身份验证和授权平台

至此，您了解了jwt令牌、用户/密码、用户表等

但是您需要确保具有“来宾”角色的用户不能对api restendpoint执行DELETE调用 /user/100.因此您需要规则

实现此规则的经典解决方案是在数据库中有一些表，如：user、roles、user\u roles、role\u permission、permission\u option。选项表必须已注册所有apiendpoint及其方法。此外，这还可用于创建用户之间的关系

您可以考虑以前的规则来开发自己的安全平台，或者使用一些称为oAuth2平台/提供者、身份/访问平台等的平台：

• auth0

更多详细信息请参见：https://stackoverflow.com/a/62049409/3957754

• 似乎OAuth2与SSO不同，它们如何协同工作

总之，SSO只是确保所有用户都可以使用相同的用户/密码访问应用程序和网站。

Oauth2与授权严格相关，但使用身份验证无法进行授权，身份验证与用户/密码相关，因此这就是Oauth2和sso之间的关系

• https://stackoverflow.com/a/63093136/3957754
• https://stackoverflow.com/a/62049409/3957754

Answer 2

如果您正在构建新的东西，请继续使用OAuth 2.0。与SAML相比，它对用户友好（基于ie-JSON）并且也很现代。此外，还有许多资源可以帮助您（ie-库和IDP适配）。还有一件事，既然您想要身份验证，您应该使用OpenID Connect（规范）。我们将其视为基于OAuth 2.0构建的简单扩展。

1但在我们的应用程序中，每个子系统究竟可以处理什么？SP还是客户端？

OAuth 2.0定义了几种不同的应用程序类型（read）。按照您的解释，在您的系统web应用程序中，它们很少

• IDP-您的身份服务器

资源服务器（SP）可以是这些应用程序的后端。或者，它可以是一种常见的后端服务。但在任何情况下，它都必须受到每个客户端获得的OAuth令牌的保护。

令牌内省（spec-rfc7662）定义了如何从资源服务器验证令牌。关于IDP的负载，这完全取决于部署的扩展。

2应用中的规则

现在我们来看看OpenID连接。它定义了ID令牌，用于向客户端传达最终用户的身份验证状态。它以JWT的形式出现。JWT的优点是（除了是JSON之外），它可以有自定义声明。规范支持这一点（其他声明）。因此，在您的IDP中，您必须配置角色/用户组/权限，并将此ID令牌传递给客户端。

3会话同步

IDP使用浏览器会话来提供您的客户端SSO行为。当您登录到一个客户端时，您的IDP会创建一个会话。因此，当最终用户使用另一个客户端时，IDP可以检查已经登录的状态，请求缺少权限并完成登录流程，发出所需的令牌。

OpenID Connect附带会话管理规范（源代码），它为您的客户端提供了一种机制来验证此会话中的更改。请向您选择的IDP咨询对此的支持。

4个Idp连接到另一个Idp

这超出了OAuth2.0生态系统的范围。SAML有一个SAML联盟来做这件事（注意，我不是SAML专家）。不同的身份提供者有自己的解决方案（例如：-WSO2带来自己的身份）。这种用户配置取决于您的需求以及IDP功能。但正如我所说，它超出了OAuth的范围。

注意-关于第四个问题，如果您的IDP支持，并且您对其满意，您可以接受第三方（即Google、Facebook）发行的代币来验证应用程序的用户身份。这可以在OpenID Connect上完成。此外，还存在允许跨不同身份提供者查询用户数据的SCIM（资源）。

Answer 3

我想我会加入到讨论中，并给出一些现实世界中最有效的模式反馈。许多OAuth行话没有帮助，使人困惑。马克·卡文杜是公认的答案。。。

Q1子系统

软件生产公司通常希望构建一个UI和API平台。大多数情况下，用您的术语来说，UI是客户端（它们获得令牌），API是子系统（它们接收令牌）。也有一些例外，如后端客户端，但这些往往是次要的。

SAML是服务器端web应用程序使用的一种旧技术，目前仍用于联合登录。如今，大多数公司都想构建移动应用程序和基于Javascript的应用程序，OAuth 2就是针对这些应用程序开发的。正如Kavindu所说，x和Open Id Connect更适合许多库。

Q2.规则

这里的一种选择是管理授权服务器中的规则。例如，您可以将OAuth自定义范围用作高级权限，然后将其添加到访问令牌并由API读取：

• 订单范围表示您可以执行与订单相关的操作

这对于简单的应用程序可能没问题。对于更复杂的应用程序，它不能很好地扩展，并且存在订单API的范围/声明开始对产品API产生不利影响的风险。

更复杂的规则属于API，随着时间的推移，它们更容易管理。这通常涉及从子系统自身数据中的访问令牌查找用户。

我个人的偏好是使用基于声明的体系结构来最好地执行规则。如果对这种方法感兴趣，请参阅下面我的博客帖子：

• 用户数据管理
• 基于API声明的授权

问题3.会话html" target="_blank">同步

有时，这是一个基于OAuth的系统无法按涉众期望的方式运行的领域，人们只需要了解技术的局限性。最终用户不会在意单次注销是否有效，您也不会错过安全审查。

例如，在移动设备上，注销浏览器用户界面不会将您注销移动用户界面。移动用户界面将继续使用短期访问令牌，但访问令牌过期时将提示用户再次登录——可能是30分钟后。

问题4：联合会

大多数授权服务器可以与多个身份提供者联合，以支持多种登录类型。在企业界，这通常使用SAML 2.0作为协议。您允许哪些提供者通常取决于子系统处理的资产类型：

• 对于公司资产，您不允许用户使用其Facebook帐户登录

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