总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 ximeneschen.blog.csdn.net/article/details/115182080 「ximeneschen」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

一、概述

SSO是Single Sign On的缩写，OAuth是Open Authority的缩写，这两者都是使用令牌的方式来代替用户密码访问应用。流程上来说他们非常相似，但概念上又十分不同。SSO大家应该比较熟悉，它将登录认证和业务系统分离，使用独立的登录中心，实现了在登录中心登录后，所有相关的业务系统都能免登录访问资源。

OAuth2.0原理可能比较陌生，但平时用的却很多，比如访问某网站想留言又不想注册时使用了微信授权。以上两者，你在业务系统中都没有账号和密码，账号密码是存放在登录中心或微信服务器中的，这就是所谓的使用令牌代替账号密码访问应用。

二、SSO

两者有很多相似之处，下面我们来解释一下这个过程。先来讲解SSO，通过SSO对比OAuth2.0，才比较好理解OAuth2.0的原理。SSO的实现有很多框架，比如CAS框架，以下是CAS框架的官方流程图。特别注意：SSO是一种思想，而CAS只是实现这种思想的一种框架而已

上面的流程大概为：

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

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

三、OAuth2.0

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

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

  • 用户在某网站上点击使用微信授权，这里的某网站就类似业务系统，微信授权服务器就类似单点登录系统
  • 之后微信授权服务器返回一个确认授权页面，类似登录界面，这个页面当然是微信的而不是业务系统的
  • 用户确认授权，类似填写了账号和密码，提交后微信鉴权并返回一个ticket，并重定向业务系统。
  • 业务系统带上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是用来允许用户授权第三方应用访问他在另一个服务器上的资源的一种协议，它不是用来做单点登录的，但我们可以利用它来实现单点登录。在本例实现SSO的过程中，受保护的资源就是用户的信息（包括，用户的基本信息，以及用户所具有的权限），而我们想要访问这这一资源就需要用户登录并授权，OAuth2服务端负责令牌的发放等操作，这令牌的生成我们采用JWT，也就是说JWT是用来承载用户的Access_Token的

最后，Spring Security、Shiro是用于安全访问的，用来做访问权限控制，都是一个用Java写的框架

文章目录
  1. 1. 一、概述
  2. 2. 二、SSO
  3. 3. 三、OAuth2.0
    1. 3.1. 简介一下OAuth2.0的四种模式：
      1. 3.1.0.1. 授权码（authorization-code）
      2. 3.1.0.2. 隐藏式（implicit）
      3. 3.1.0.3. 密码式（password）
      4. 3.1.0.4. 客户端凭证（client credentials）
  • 4. 四、说一下几个名词的区别