基于 OAuth2 的 SSO [英] OAuth2 based SSO

查看:76
本文介绍了基于 OAuth2 的 SSO的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们的项目由几个子应用程序组成,我们正在寻找一种解决方案来实现 SSO 以避免对每个子应用程序进行身份验证.

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

身份验证服务器(称为 AS 或 IdP 或其他名称)订单系统产品系统数据分析系统......

而且我们发现有很多基于OAuth2实现SSO"的文章;像

OAuth2 中的 1 条规则

<块引用>

资源服务器 (SP) – 这是您尝试访问的网络服务器信息.

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

授权服务器(Idp)——这是拥有用户的服务器身份和凭据.这是用户实际验证的人并授权.

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

  • 客户

    • 现代网络(react、angular、vue、linkstart 等)和移动应用(android/ios).一般来说,任何需要来自另一个软件的数据的软件都可以成为客户端.通常客户端是一个网络,请求的数据是一个 http api rest,但这个概念可以适用于遗留(服务器渲染应用程序)或未来的应用程序(商场中的机器人)
  • 资源服务器

    • Http Rest API.保持简单!!我们谈论的是用某种后端语言(java、python、nodejs 等)开发的 API,可从 Postman、Soapui、curl、javascript 等使用
  • 授权服务器

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

问题第 2 部分

  • 那么规则配置应该在哪里进行?在 Idp 中还是在每个子系统中?
  • 除了基本的用户名和密码登录,身份验证服务器应提供来自 google、facebook 和其他CAS 提供商也是如此.这可能吗?

身份验证和授权平台

此时你知道了 jwt 令牌、用户/密码、用户表等

但是您需要确保具有guest"的用户角色无法对 api 休息端点/user/100 执行 DELETE 调用.所以你需要规则

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

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

  • auth0
  • 钥匙扣等

更多详情:https://stackoverflow.com/a/62049409/3957754


问题第 3 部分

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

总而言之,SSO 只是确保您的所有用户都可以使用相同的用户名/密码访问应用和网站.

Oauth2授权严格相关,但是认证无法授权,而认证与用户/密码相关,所以这个是oauth2和sso的关系

一些链接

Our project consists several sub application, and we are looking for a solution to implement SSO to avoid the authentication for each sub application.

Suppose this is the structure of our project:

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

And we found that there are a lot of articles of "SSO implemented based on OAuth2" like this.

In that article, we prefer to the SAML strategy because it is simple and clear, however there are some limitations for native application, then we focused on the OAuth2.

This is the work flow:

1 Rules in OAuth2

Resource Server (SP) – this is the web-server you are trying to access information 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 desktop app, a server-side app.

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

Take OctoDroid as an example, the rules are very clear:

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

The workflow is that OctoDroid(Client) ask you(User) to login and grant permissions through Github(Idp) to get the resources(repos,issues) from Github(SP).

But in our application, what exactly can each sub-system treated? a SP or a Client ?

If treated as a SP, is web browser the Client? I always thought that a Client should be an application. Also the sub-system validate the access_token through Idp for each request and then return the related resource, will this increase the pressure to the Idp?

If treated as a Client, who is the SP?

2 Rules in application

For a same user, he may have different rules in different sub-systems, for example, he can read/write all the orders from order-system, but he can not access the product-system. Then where should the rules configuration happen? In the Idp or in each sub-system?

3 Session Synchronization

For a typical SSO system, when user login(through Idp), all sub-system should login, when user logout , all sub-system should logout.

However in the above OAuth2 workflow, it seems that different SPs or Clients are independent. When you logout from OctoDroid, you can still use OpenHub once you have login. In this case, it seems like OAuth2 is different from SSO, how can they work together?

4 Idp connect to another Idp

In our application, In addition to the basic username and password login, the authentication server should provide login from google,facebook and other CAS providers too. Is this possible?


BTW, I am not sure if I have made myself clear enough, if not, ask me in the comments.

解决方案

You have a lot of questions.

Questions Part 1

  • But in our application, what exactly can each sub-system treated? a SP or a Client ?
  • If treated as a SP, is web browser the Client?
  • If treated as a Client, who is the SP?

I think these questions are related to : OAuth 2.0 four roles

Oauth2 Roles

Let's start with this classic flow diagram:

You can use these rules to determine what role your applications have:

  • Client

    • 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)
  • Resource Server

    • 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
  • Authorization Server

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

Questions Part 2

  • Then where should the rules configuration happen? In the Idp or in each sub-system?
  • In addition to the basic username and password login, the authentication server should provide login from google,facebook and other CAS providers too. Is this possible?

Authentication and Authorization platforms

At this point you know about jwt tokens, user/password, users table, etc

But you need to ensure that a user with "guest" role cannot execute a DELETE invocation to an api rest endpoint /user/100. So you need RULES

Classic solution to implement this rules is to have some tables in your database like: user, roles, user_roles, role_permission, permission_option. Option table must have registered all your api endpoints and its method. Also this could be used to create the relation between user <:> web routes. Check this

You could develop your own security platform taking into consideration the previous rules or use some platforms called oauth2 platform/providers, Identity/Access Platforms, etc:

  • auth0
  • keycloack, etc

More details here: https://stackoverflow.com/a/62049409/3957754


Questions Part 3

  • it seems like OAuth2 is different from SSO, how can they work together?

As a summary, SSO just ensures that all your user could access to apps and webs with the same user/password.

Oauth2 is strictly related to authorization, but authorization is not possible with authentication, and authentication is related to user/password, so this is the relationship between oauth2 and sso

Some links

这篇关于基于 OAuth2 的 SSO的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆