# spring-cloud-starter-oauth2-demo

#### 介绍
本项目基于spring-cloud-starter-oauth2搭建的认证中心和资源服务器的微服务项目，项目不仅仅简单的demo，项目的出发点在于实战应用。本项目为笔者花了不少时间和精力整理出来的，只需要稍微调整就可应用于实际项目当中，并且项目包含大量注释，不仅可以让你会用，也可让你了解到一些流程、一些原理上的东西。认证中心完成密码模式、授权码模式、刷新token模式、简化模式、以及自定义的手机号验证码模式。

#### 软件架构
软件架构说明

功能
- 密码模式
- 自定义手机验证码模式
- 授权码模式
- 简化模式
- 刷token模式
- 退出测试接口
- 简单授权页面
- 不需要accessToken测试接口
- 需要accessToken测试接口
- 需要特定权限测试接口
- scope测试接口

#### 安装教程

1.  xxxx
2.  xxxx
3.  xxxx

#### 使用说明

一：oauth2认证
  oauth2主要是对系原系统的认证管理，其中认证的主要流程分为4：oauth2流程认证。然后我自己做了一下理解
二：授权码模式
  1.授权流程
![输入图片说明](https://images.gitee.com/uploads/images/2020/1021/223255_f0cd06c9_1791572.png "授权码模式.png")

2.交互过程

一共是5次交互，3次必要性交互，2次非必须交互

第一次必要性交互：第三方和用户服务器的交互（即图中的第一步和第二步），其中产出了临时授权码code

第二次必要性交互：第三方和认证服务器的交互（即图中的第三步和第五步），其中产出access token

第一次非必须交互（即图中的第四步）：认证服务器校验授权码和身份凭证，这里可能是与用户服务器，                                                                                                                 也可能是在临时缓存  中获取并校验。

第三次必要性交互：第三方和资源服务器的交互（即图中的第六步和第八步）：第三方获取到需要的资源

第二次非必须的交互（即图中的第七步）：认证access token，其他同上。

3.优缺点：

优点是：用户可以控制自身的一些权限是否给第三方，第三方只能获取到用户临时产生的一个访问的code，安全性。

缺点是：认证过程繁琐，但实际上从安全考虑，我认为这个缺点可忽略不计

4.常见的应用场景：各大应用内的qq，微信登录等。

5.场景分析：比如csdn内的qq登录

a.主要就是你点qq登录，会跳转到qq登录的页面，这是的请求已经跳转到qq服务器了，然后你输入账号或者

扫码登录，这是所有请求都在qq服务器完成的。

b.正确登录后，qq服务器返回用户的code，然后csdn再去请求信息。（这一步用户不可见）

c.csdn获取到qq名称，头像等。

三：密码模式
 1.流程说明
![输入图片说明](https://images.gitee.com/uploads/images/2020/1021/223402_2b150157_1791572.png "密码模式.png")
2，交互说明：

一种产生了4次交互，2次必须，2次非必须。

第一次必要交互：第三方和认证服务器交互（即图中的第一步和第三步），注意这里用户直接给与了第三方账号和密码了。

第一次非必须交互（即图中的第二步）：认证服务器校验账号密码和身份凭据

第二次不要交互：第三方和资源服务器交互（即图中的第四步和第六步），返回所需数据信息

第二次非必须交互（即图中的第五步）：认证服务器校验access token

3.优缺点

这种授权方式向第三方直接暴露了用户的账号密码既不安全。这种方式适用于一些比较大出名的第三方。

4.实际案例：qq客户端内的qq游戏大厅登录qq游戏大厅（或者说同一个生态体系内的相互登录）

5.案例分析：

a.在qq客户端通过右下角的qq游戏大厅的图标登录。

b.在弹出的游戏大厅的登录界面可以看到用户的账号密码。

四：简化模式
  1.流程说明
![输入图片说明](https://images.gitee.com/uploads/images/2020/1021/223501_fbb8442f_1791572.png "简化模式.png")
2.交互说明

一共4次必要交互，2次非不要交互（图中并没有画出，主要就是验证token等数据）

第一次：第三方将用户导向认证服务器（即图中第一步）

第二次：认证服务器跳转到转向服务器（即图中第二步），这里是当用户同意授权时，将access token放入浏览器的hash部分

第三次：跳转服务器的下一步（这里产生了2个分支）

第三步分支1和下一步：这里是跳转服务器解析出hash中的access token并将其返回给第三方，迪桑饭拿着去请求资源

第三步分支2：跳转服务器解析出access token，直接访问资源服务器

第四次：资源服务器返回资源给第三方

3.优缺点

这种模式缺点较大：整个过程所有的url都暴露在浏览器中，信息安全度较低。

4.实际场景分析：这种模式直接就不建议用。

五：客户端模式
 1.流程说明
![输入图片说明](https://images.gitee.com/uploads/images/2020/1021/223550_caa00c6a_1791572.png "客户端模式.png")

2.说明：

从流程中，这个模式不涉及用户。这里我就不说明，应该都能看得懂吧。

认证验证流程
这里简单做下密码模式的认证和accessToken验证流程，手机号模式跟这个类型，授权码模式和简化模式稍微有点不一样，授权码模式和简化模式都是先跳到认证中心的授权页面，授权成功后回调回调地址，并且携带参数code或accessToken。

![输入图片说明](https://images.gitee.com/uploads/images/2020/1021/223749_9a264758_1791572.png "认证验证流程.png")

#### 参与贡献

1.  Fork 本仓库
2.  新建 Feat_xxx 分支
3.  提交代码
4.  新建 Pull Request

#### 特技

1.  使用 Readme\_XXX.md 来支持不同的语言，例如 Readme\_en.md, Readme\_zh.md
2.  Gitee 官方博客 [blog.gitee.com](https://blog.gitee.com)
3.  你可以 [https://gitee.com/explore](https://gitee.com/explore) 这个地址来了解 Gitee 上的优秀开源项目
4.  [GVP](https://gitee.com/gvp) 全称是 Gitee 最有价值开源项目，是综合评定出的优秀开源项目
5.  Gitee 官方提供的使用手册 [https://gitee.com/help](https://gitee.com/help)
6.  Gitee 封面人物是一档用来展示 Gitee 会员风采的栏目 [https://gitee.com/gitee-stars/](https://gitee.com/gitee-stars/)

zhouhailong/spring-cloud-starter-oauth2-demo

简介

发行版

贡献者

近期动态

zhouhailong/spring-cloud-starter-oauth2-demo .gitee-modal { width: 500px !important; }

简介

发行版

贡献者

近期动态

搜索帮助

zhouhailong/spring-cloud-starter-oauth2-demo