问基于OAuth2的单点登录

EN

如果您正在构建新的东西，那么继续使用OAuth 2.0。与SAML相比，它是用户友好的(基于is的)，也是现代的。此外，还有许多资源可以帮助您解决问题(例如库和IDP适应)。还有一件事，因为您想要身份验证，所以应该使用OpenID连接(等级库)。我们可以把它看作是构建在OAuth 2.0上的一个简单的扩展。

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

OAuth 2.0定义了很少不同的应用程序类型(朗读)。按照你的解释，在你的系统中很少有这样的程序-- web应用程序&本地应用程序(可能是移动的)。如果是这样的话，

• IDP -您的身份服务器
• 客户端-您开发的所有应用程序
• 用户代理-用于激活OAuth流的浏览器
• 最终用户-系统的用户。

资源服务器(SP)可以作为这些应用程序的后端.或者是一种普通的后端服务。但是在任何情况下，它都必须由每个客户端获得的OAuth令牌来保护。

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

应用程序中的2规则

现在我们来看看OpenID连接。它定义了ID令牌，该令牌与客户端就最终用户的身份验证状态进行通信。它以一种JWT的形式出现。JWT的好处是(除了是JSON)，它还可以有自定义声明。规范支持这一点(额外索赔)。因此，在您的IDP中，您必须配置角色/用户组/权限，并在ID令牌中将其传递给客户端。

3会话同步

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

OpenID连接附带了会话管理规范(来源)，它为客户端提供了一种机制来验证此会话中的更改。请检查您选择的IDP对此的支持。

4 Idp连接到另一个Idp

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

注意-About第四个问题，如果你的国内流离失所者支持，如果你对此没意见，你可以接受第三方(比如谷歌，Facebook)发布的令牌来验证应用程序的用户。这可以在OpenID连接的基础上完成。此外，还存在SCIM (资源)，它允许跨不同身份提供者查询用户数据。

我想我会加入到讨论中来，在现实世界中，我会对那些最有效的模式进行反馈。许多OAuth术语是没有帮助的，让人感到困惑。马克·卡文杜是公认的答案..。

Q1.子系统

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

SAML是服务器端web应用程序使用的一种古老技术，目前仍用于联邦登录。如今，大多数公司都希望开发基于OAuth 2.x和Open的移动应用程序和基于Javascript的应用程序。

Q2.规则

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

• 订单范围意味着您可以执行与订单相关的操作。
• 产品+写作用域意味着您可以更新产品系统

对于简单的应用程序来说，这可能很好。对于更复杂的应用程序，它不能很好地扩展，而且对于Order的作用域/声明可能会开始对Products产生不利影响。

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

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

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

Q3.会话同步

有时，这是一个基于OAuth的系统不符合涉众预期的领域，人们只需要了解该技术的局限性。最终用户不会在意单次注销是否有效，而且您也不会失败安全检查。

例如，在移动设备上，注销浏览器UI不会将您从mobile中注销。Mobile将继续使用短暂的访问令牌，但是当访问令牌过期时，用户将再次被提示登录--大约30分钟后。

Q4.联邦

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

• 对于公司资产，您不允许用户登录他们的Facebook帐户
• 对于个人资产来说，这可能是可以的。

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

你有很多问题。

问题第1部分

• 但是在我们的应用程序中，每个子系统究竟可以处理什么呢？SP还是客户？
• 如果作为SP处理，web浏览器是客户端吗？
• 如果作为客户处理，谁是SP？

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

Oauth2 Roles

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

​

​

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

• 客户端

- Moderns web (react, angular, vue, linkstart, etc) and mobile apps(android/ios). In general way, any piece of software who needs **data** from another piece of software could be a **client**. Commonly the client is a web and the requested data is an http api rest but the concept could apply to legacy (server rendering apps)  or future apps (robots in a mall)

• 资源服务器

- Http Rest Api. **Keep it simple!!** we are talking about an api developed in some backend language (java, python, nodejs, etc) consumable from Postman, Soapui, curl, javascript, etc

• 授权服务器

- Application which is in charge of token generations and more features related to the **security** of your applications

问题第二部分

• 那么，规则配置应该在哪里发生呢？在国内流离失所者或每个子系统中？
• 除了基本的用户名和密码登录外，认证服务器还应该提供来自google、facebook和其他CAS提供商的登录。这个是可能的吗？

认证与授权平台

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

但是，您需要确保具有“来宾”角色的用户不能执行对api端点/ user /100的删除调用。所以你需要规则

实现此规则的经典解决方案是在数据库中有一些表，如:用户、角色、user_roles、role_permission、permission_option。选项表必须已注册了所有api端点及其方法。此外，这也可以用于创建用户<:>网络路由之间的关系。检查这

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

• auth0
• 钥匙孔等

这里有更多详细信息：https://stackoverflow.com/a/62049409/3957754

问题3

• OAuth2似乎与单点登录不同，它们如何协同工作？

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

authorization，与 oauth2 有着严格的联系，但是authentication，不允许授权，身份验证与用户/密码有关，所以这是oauth2和sso之间的关系。

一些链接

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