OAuth2.0与SSO比较

Posted 2022-02-18 馥钰

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了OAuth2.0与SSO比较相关的知识，希望对你有一定的参考价值。

OAuth2.0与SSO比较_咖啡男孩之SRE之路-CSDN博客_oauth2.0与sso

OAuth是Open Authority的缩写，是令牌代替用户密码访问应用的又一标准，前面一期介绍过SSO单点登录（SpringBoot模拟单点登录），也是令牌登陆的一种方式。

OAuth2.0最典型的授权码认证方式：

资源服务器和鉴权服务器都是属于资源所有方，也就是最终的服务提供方，第三接入方需要先与鉴权服务器申请合作获取客户编码。

对于资源服务器来说，需要做的是

1 accessToken和clientId的校验

2 token校验通过后要对token访问权限做好限制

对于鉴权服务器来说，需要做的是

1 接受第三方应用的申请，维护clientId

2 提供登入页面，做用户、密码鉴权

3 授权码生成和验证

4 token的生成

5 clientId、token的维护，一般clientId入库，token入内存

OAuth2.0最主要的是授权码方式和简单方式，简单方式就是省略了上面客户端获取code然后交换token的过程。

OAuth2.0网上资料经常拿来跟SSO混为一谈，个人觉得这两个概念一定要区分开，根本是两回事。SSO是登录自己公司的多个产品，一处登录，多处同时登录，OAuth2.0访问第三方资源的一种标准方式，两者解决的问题是有区别的！

SSO是为了解决一个用户在鉴权服务器登陆过一次以后，可以在任何应用中畅通无阻，一次登陆，多系统访问，操作用户是实打实的该应用的官方用户，用户的权限和分域以鉴权服务器的存储为准。

OAuth2.0 解决的是通过令牌获取某个系统的操作权限，因为有 clientId 的标识，一次登陆只能对该系统生效，第三方应用的操作用户不是鉴权系统的官方用户，授权权限鉴权中心可以做限制。

oauth2.0与单点登录_炎升的博客-CSDN博客_oauth2.0单点登录

1、什么是 OAuth2.0
OAuth （Open Authority的缩写）是一个开放标准，该标准允许用户让第三方应用访问该用户在某一网站上存储的私密资源（如头像、照片、视频等），而在这个过程中无需将用户名和密码提供给第三方应用。实现这一功能是通过提供一个令牌（token），而不是用户名和密码来访问他们存放在特定服务提供者的数据。采用令牌（token）的方式可以让用户灵活的对第三方应用授权或者收回权限。

OAuth2.0 是 OAuth 协议的下一版本，但不向下兼容 OAuth 1.0。传统的 Web 开发登录认证一般都是基于 session 的，但是在前后端分离的架构中继续使用 session 就会有许多不便，因为移动端（android、ios、微信小程序等）要么不支持 cookie（微信小程序），要么使用非常不便，对于这些问题，使用 OAuth2 认证都能解决。

对于大家而言，我们在互联网应用中最常见的 OAuth2 应该就是各种第三方登录了，例如 QQ 授权登录、微信授权登录、微博授权登录、GitHub 授权登录等等。

1.1、Auth2协议中，共有四个参与方(角色)：
1.resource owner：资源拥有者，即用户。
2.resource server：资源服务器。即存储用户数据的服务器，一般对外都以RESTFul API的形式暴露用户数据，client使用access token访问resource server申请被保护起来的用户数据。
3.client：客户端。即第三方应用。
4.authorization server：授权服务器。用来鉴权第三方应用合法性，并对用户登录、是否授权第三方应用获取数据进行响应，并根据用户操作，向第三应用颁发code 或用户token或者告知授权失败。
2、什么是单点登录？
单点登录的英文名是 Single Sign On，因此一般简称为SSO。它的用途在于，不管多么复杂的应用群，只要在用户权限范围内，那么就可以做到，用户只需要登录一次就可以访问权限范围内的所有应用子系统。对于用户而言，访问多个应用子系统只需要登录一次，同样在需要注销的时候也只需要注销一次。举个简单的例子，你在百度首页登录成功之后，你再访问百度百科、百度知道、百度贴吧等网站也会处于登录状态了，这就是一个单点登录的真实案例。

重要的是理解：

SSO服务端和SSO客户端直接是通过授权以后发放Token的形式来访问受保护的资源；
相对于浏览器来说，业务系统是服务端，相对于SSO服务端来说，业务系统是客户端；
浏览器和业务系统之间通过会话正常访问；
不是每次浏览器请求都要去SSO服务端去验证，只要浏览器和它所访问的服务端的会话有效它就可以正常访问。

2.2. OAuth2

3、OAuth2.0授权与单点登录的区别
根据OAuth2.0授权与单点登录的概念，我们可以得知二者至少存在以下几点区别：

从信任角度来看。OAuth2.0授权服务端和第三方客户端不属于一个互相信任的应用群（通常都不是同一个公司提供的服务），第三方客户端的用户不属于OAuth2.0授权服务端的官方用户；而单点登录的服务端和接入的客户端都在一个互相信任的应用群（通常是同一个公司提供的服务），各个子系统的用户属于单点登录服务端的官方用户。
从资源角度来看。OAuth2.0授权主要是让用户自行决定——“我”在OAuth2.0服务提供方的个人资源是否允许第三方应用访问；而单点登录的资源都在客户端这边，单点登录的服务端主要用于登录，以及管理用户在各个子系统的权限信息。
从流程角度来看。OAuth2.0授权的时候，第三方客户端需要拿预先“商量”好的密码去获取Access Token；而单点登录则不需要。
4、OAuth2 协议一共支持 4 种不同的授权模式：
授权码模式：常见的第三方平台登录功能基本都是使用这种模式。

简化模式：简化模式是不需要客户端服务器参与，直接在浏览器中向授权服务器申请令牌（token），一般如果网站是纯静态页面则可以采用这种方式。

密码模式：密码模式是用户把用户名密码直接告诉客户端，客户端使用说这些信息向授权服务器申请令牌（token）。这需要用户对客户端高度信任，例如客户端应用和服务提供商就是同一家公司，我们自己做前后端分离登录就可以采用这种模式。

客户端模式：客户端模式是指客户端使用自己的名义而不是用户的名义向服务提供者申请授权，严格来说，客户端模式并不能算作 OAuth 协议要解决的问题的一种解决方案，但是，对于开发者而言，在一些前后端分离应用或者为移动端提供的认证授权服务器上使用这种模式还是非常方便的。

4.1、授权码模式
授权码模式是最安全并且使用最广泛的一种模式。以www.javaboy.org 为例，假如我要引入微信登录功能，那么我的流程可能是这样：

在授权码模式中，我们分授权服务器和资源服务器，授权服务器用来派发 Token，拿着 Token 则可以去资源服务器获取资源，这两个服务器可以分开，也可以合并。

上面这张流程图的含义，具体是这样：

首先，我会在我的 www.javaboy.org 这个网页上放一个超链接（我的网站相当于是第三方应用），用户 A （服务方的用户，例如微信用户）点击这个超链接就会去请求授权服务器（微信的授权服务器），用户点击的过程其实也就是我跟用户要授权的过程，这就是上图中的 1、2 步。

接下来的第三步，就是用户点击了超链接之后，像授权服务器发送请求，一般来说，我放在 www.javaboy.org 网页上的超链接可能有如下参数：

https://wx.qq.com/oauth/authorize?response_type=code&client_id=javaboy&redirect_uri=www.javaboy.org&scope=all
这里边有好几个参数，在后面的代码中我们都会用到，这里先和大家简单解释一下：

response_type 表示授权类型，使用授权码模式的时候这里固定为 code，表示要求返回授权码（将来拿着这个授权码去获取 access_token）。

client_id 表示客户端 id，也就是我应用的 id。有的小伙伴对这个不好理解，我说一下，如果我想让我的 www.javaboy.org 接入微信登录功能，我肯定得去微信开放平台注册，去填入我自己应用的基本信息等等，弄完之后，微信会给我一个 APPID，也就是我这里的 client_id，所以，从这里可以看出，授权服务器在校验的时候，会做两件事：1.校验客户端的身份；2.校验用户身份。

redirect_uri 表示用户登录在成功/失败后，跳转的地址（成功登录微信后，跳转到 www.javaboy.org 中的哪个页面），跳转的时候，还会携带上一个授权码参数。

scope 表示授权范围，即 www.javaboy.org 这个网站拿着用户的 token 都能干啥（一般来说就是获取用户非敏感的基本信息）。

3、接下来第四步，www.javaboy.org 这个网站，拿着第三步获取到的 code 以及自己的 client_id 和 client_secret 以及其他一些信息去授权服务器请求令牌，微信的授权服务器在校验过这些数据之后，就会发送一个令牌回来。这个过程一般是在后端完成的，而不是利用 js 去完成。

4、接下来拿着这个 token，我们就可以去请求用户信息了。

一般情况下我们认为授权码模式是四种模式中最安全的一种模式，因为这种模式我们的 access_token 不用经过浏览器或者移动端 App，是直接从我们的后台发送到授权服务器上，这样就很大程度减少了 access_token 泄漏的风险。