理论篇(一) Spring Security+OAuth2 权限服务

目录

 

首先什么是OAuth2

Spring  Security又是什么

为什么用OAuth2

整个流程图

交互过程

第三方接入

Access Token令牌刷新

Refresh Token

客户端授权模式

概述

简化模式

授权码模式

密码模式

客户端模式

总结

声明

---

首先什么是OAuth2

• oAuth2是一种协议，可以理解为是一种标准
• 特点在与不会让第三方触及到用户的账户信息，比如用户名和密码
• 可以在不使用账户名和密码的情况下获取到用户所授权的用户资源，所以OAuth2是安全的

Spring  Security又是什么

• Spring Security是Spring家族里的一个安全框架，有了解过的同学应该很清楚Spring Security能够为Spring企业应用系统提供声明式的安全访问控制
• Spring Security基于Servlet过滤器，IOC和AOP，为 Web请求和方法调用提供身份确认和权限处理，避免了代码耦合，减少大量重复代码工作

为什么用OAuth2

假设你有一个“云笔记”产品，分别有“云笔记服务”和“云相册服务”，用户则需要在不同的(pc,Android,iphone,tv,Watch)设备上来访问这些资源（“云笔记”，“云相册”）,用户如何访问到属于用户自己的资源呢，传统的做法是用户提供账户和密码给“云笔记”，登陆成功后就可以获取到资源了，但是会产生以下几种问题：

1. “云笔记服务”，“云相册服务”是分别部署的，也就是分布式部署方式，难道需要一个一个服务的登陆后才能访问？也就是单点登陆问题
2. 公司有合作企业想要接入到我们的“云笔记”，不可能不本公司用户的账户和密码给到合作企业然后让他记录我们的用户信息吗？这不合适吧
3. 如何限制第三方在我们“云笔记”的授权范围和使用期限呢？
4. 如果使用账户密码登陆，假设有一个第三方应用别破解，那么就意味着用户和密码的泄露
5. ......

而OAuth2可以帮我们解决这些个问题

基本流程图

 

交互过程

核心思想就是，客户端不可以直接访问资源服务器，必须经过认证服务器

第三方接入

比如说我“云笔记”要实现QQ登陆。

1. 其业务流程首先是打开云笔记客户端，然后有支持QQ登陆的这么一个按钮，点击后调用QQ支持的登陆页面(图一)
2. 在用户扫码或者输入密码后点击授权登陆的时候会访问QQ的认证服务器，然后确认核实后QQ认证服务器会返回一个授权码给“云笔记”客户端
3. “云笔记”客户端根据这个授权码再去QQ认证服务器获取到“资源令牌”，QQ认证服务器确认授权码无误后返回一个“资源令牌”
4. 最后“云笔记”客户端再去QQ资源服务器调用用户资源，比如(用户昵称，头像，性别......)

这样就可以做到不使用账户和密码就进行登陆，简单来说就是给你自动做了一个简单的注册，只是信息没有那么全面，而且完成QQ登陆后还要进行手机号注册，不然光是昵称这些不足以知道你到底是谁

还有值得注意的一点就是在授权的时候在下面会显示给谁授权，要给他什么东西，如图一所示我要给有道云授权，可以获取我的昵称和头像还有性别

图一

Access Token令牌刷新

在上面我们提到了资源访问令牌,知道了可以根据这个令牌来访问我们所需要的资源，但是这个access token是保存在客户端上面的，而且是个临时的，因为在客户端上就会有泄露的风险如下图，可以抓包获取到你的access token，而给access token定制一个有效期限可以在一定程度上面防止泄露风险。

但是一旦设置了临时期限的时候，客户端就不是那么方便了。每次access token一过期就要重新向用户索要授权。这样用户每次可能过一天或者几天（根据程序设定时间来算）就要重新进行一次授权操作，会影响使用体验感。

为了解决这一问题，OAuth2引入了Refresh Token机制

Refresh Token

其作用就是用来刷新Access Token。认证服务器提供一个接口刷新，如下图一所示。传入refresh_token和client_id，认证服务器验证通过后，返回一个新的Access token，但是为了安全，OAuth2.0采取了两个措施

1. 要求Refresh Token一定是保存在服务器端，也就是后台，一定不能放在如(pc端，app软件)，调用refresh接口时，一定是从服务器到服务器器之间的访问
2. OAuth2.0引入了client_secret机制，就是每一个client_id对应每一个client_secret，这个client_secret会在客户端申请client_id的时候一同返回给客户端，举个例子：微信支付中需要的App_id和App_secret就是你在有需要支付业务的时候微信支付开发平台给你分发App_id和App_secret。大概就是这个意思

假如把下面图二中的client_id和client_secret换成app_id和app_secret的话，那么对于写过微信支付对接或者登陆对接的同学是很好理解的

图一

图二

客户端授权模式

概述

客户端必须得到用户的授权(authorztion grant)，才可以获取到访问令牌(access token)。而OAuth2.0定义了四种授权方式

1. implicit：简单授权模式，官方不推荐使用，除了特定场合
2. authorztion code：授权码模式授权，官方推荐使用，安全贼高
3. resource owner password credentials：密码模式
4. cilent credentials：客户端模式

简化模式

简单来说就是在你只有APP或者纯静态HTML5页面而没有服务器(后台)的时候，你要去对接第三方的系统服务，可以使用简化模式，但是该模式下一些权限信息，比如access token就很容易泄流，而且不会刷新

授权码模式

首先从app或者小程序又或者pc端访问API网关，由于是微服务开发，所以在会有网关来处理客户端访问问题，然后由API网关来访问认证服务器，在认证服务器确认你 数据无误（是个成年人）后根据你的回调地址返回一个授权码（我18岁的身份证），这是侯你要再次通过API网关来访问认证服务器来获取到access token（哈尔滨机票），最后才是你根据这个access token去访问资源服务器，这时候你就可以获取访问资源（上飞机了）

还有一种情况就是你是去访问第三方的服务器，比如说微信登陆

这个时候访问的就不是你自己的网关了，而是别人的第三方的服务器，然后根据别人的第三方服务器访问别人第三方的认证服务器，和上面相比就是，不管是API也好，还是认证服务器也好，或者是资源服务器也好，这些都是别人家的?，不是亲爹

密码模式

要求输入账户和密码，之前我们说了吧自己家的用户信息给到别人家是不好的，但是假设下图，云笔记和云网盘都是自家研发的产品那么就需要自己一套专门定制的登陆页面和接口登入，比如登陆云笔记后我又需要获取云网盘的资源，这时就可以在云笔记的服务上面直接用密码和账户调用云网盘的登陆接口从而实现认证并且获取资源，反之也是一样的

客户端模式

官方描述是假如两家或者多家企业之间的信任关系跟进一步，比如说是合作企业（一条绳上的蚂蚱），那么也是可以用户共享的，反正我GG你也凉是吧，这叫绝对信任。

还有一种就是纯后台的，没有登陆页面可是要登陆的情况下，客户端模式就上场了

不管是绝对信任还是纯后台的，都是鉴权服务器直接对客户端进行身份验证，验证通过返回token

总结

OAuth2是一种授权协议，主要作用就是为了提供这个认证和授权的规范

对于市面上对于这种协议或者标准的实现这目前是推荐两种又或者自己实现

1. Spring Security
2. Shiro

而oAuth2规范中定义了

角色

1. 资源所有者
2. 第三方程序（客户端）
3. HTTP服务提供者（认证服务器，资源服务器）

客户端授权模式

1. 简化模式 （没有后端，只有客户端，不安全，access token容易泄露）
2. 授权模式（四种模式中最安全，需要授权后才可以获取到access token）
3. 密码模式（适用于本企业不同产品之间的调用）
4. 客户端模式（适用于绝对信任合作方或者没有登陆页面而需要登陆的服务或者产品）

访问令牌

access token（获取到资源服务的凭证），refresh_token（刷新access token）

声明

视频链接来自B站UP主（鲁斯菲尔）：https://www.bilibili.com/video/av48590637/?p=8
推荐看完视频理论部分后回顾总结以下，最后进入实战