SSO 单点登录和 OAuth2.0 的区别

这是在工作中经常遇到的两个概念，但还有一些同学不是很理解，这篇文章就来详细说说。

转载信息如下：

作者：ximeneschen
链接：https://ximeneschen.blog.csdn.net/article/details/115182080

SSO 是 Single Sign On 的缩写，OAuth 是 Open Authority 的缩写，这两者都是使用令牌的方式来代替用户密码访问应用。流程上来说他们非常相似，但概念上又十分不同。

SSO 大家应该比较熟悉，它将登录认证和业务系统分离，使用独立的登录中心，实现了在登录中心登录后，所有相关的业务系统都能免登录访问资源。

OAuth2.0 原理可能比较陌生，但平时用的却很多，比如访问某网站想留言又不想注册时使用了微信授权。

以上两者，你在业务系统中都没有账号和密码，账号密码是存放在登录中心或微信服务器中的，这就是所谓的使用令牌代替账号密码访问应用。

SSO

两者有很多相似之处，下面我们来解释一下这个过程。

先来讲解 SSO，通过 SSO 对比 OAuth2.0，才比较好理解 OAuth2.0 的原理。SSO 的实现有很多框架，比如 CAS 框架。

以下是 CAS 框架的官方流程图。特别注意：SSO是一种思想，而 CAS 只是实现这种思想的一种框架而已。

上面的流程大概为：

1. 用户输入网址进入业务系统 Protected App，系统发现用户未登录，将用户重定向到单点登录系统 CAS Server，并带上自身地址 service 参数
2. 用户浏览器重定向到单点登录系统，系统检查该用户是否登录，这是 SSO（这里是 CAS）系统的第一个接口，该接口如果用户未登录，则将用户重定向到登录界面，如果已登录，则设置全局 session，并重定向到业务系统
3. 用户填写密码后提交登录，注意此时的登录界面是 SSO 系统提供的，只有 SSO 系统保存了用户的密码
4. SSO 系统验证密码是否正确，若正确则重定向到业务系统，并带上 SSO 系统的签发的 ticket
5. 浏览器重定向到业务系统的登录接口，这个登录接口是不需要密码的，而是带上 SSO 的 ticket，业务系统拿着 ticket 请求 SSO 系统，获取用户信息。并设置局部 session，表示登录成功返回给浏览器 sessionId
6. 之后所有的交互用 sessionId 与业务系统交互即可

最常见的例子是，我们打开淘宝 APP，首页就会有天猫、聚划算等服务的链接，当你点击以后就直接跳过去了，并没有让你再登录一次。

OAuth2.0

OAuth2.0 有多种模式，这里讲的是 OAuth2.0 授权码模式，OAuth2.0 的流程跟 SSO 差不多。

在 OAuth2.0 中，有授权服务器、资源服务器、客户端这样几个角色，当我们用它来实现 SSO 的时候是不需要资源服务器这个角色的，有授权服务器和客户端就够了。

授权服务器当然是用来做认证的，客户端就是各个应用系统，我们只需要登录成功后拿到用户信息以及用户所拥有的权限即可。

1. 用户在某网站上点击使用微信授权，这里的某网站就类似业务系统，微信授权服务器就类似单点登录系统
2. 之后微信授权服务器返回一个确认授权页面，类似登录界面，这个页面当然是微信的而不是业务系统的
3. 用户确认授权，类似填写了账号和密码，提交后微信鉴权并返回一个 ticket，并重定向业务系统。
4. 业务系统带上 ticket 访问微信服务器，微信服务器返回正式的 token，业务系统就可以使用 token 获取用户信息了

简介一下 OAuth2.0 的四种模式：

授权码（authorization-code）

授权码（authorization code）方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌。

这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。

隐藏式（implicit）

有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。

RFC 6749 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）“隐藏式”（implicit）。

密码式（password）

如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）。

客户端凭证（client credentials）

最后一种方式是凭证式（client credentials），适用于没有前端的命令行应用，即在命令行下请求令牌。

总结

首先，SSO 是一种思想，或者说是一种解决方案，是抽象的，我们要做的就是按照它的这种思想去实现它。

其次，OAuth2.0 是用来允许用户授权第三方应用访问他在另一个服务器上的资源的一种协议，它不是用来做单点登录的，但我们可以利用它来实现单点登录。

在实现 SSO 的过程中，受保护的资源就是用户的信息（包括，用户的基本信息，以及用户所具有的权限），而我们想要访问这一资源就需要用户登录并授权，OAuth2.0 服务端负责令牌的发放等操作，这令牌的生成我们采用 JWT，也就是说 JWT 是用来承载用户的 Access_Token 的。

以上就是本文的全部内容，如果觉得还不错的话欢迎点赞，转发和关注，感谢支持。

推荐阅读：

• Git 分支管理策略