Security--14（Spring Security Oauth初体验）

目录

 

1.为什么要开发基于App认证的模块？

2.Spring Security Oauth

3.实现标准的Oauth服务提供商

4.获取授权码

5.获取accessToken

6.实现资源服务器

---

1.为什么要开发基于App认证的模块？

   之前的认证方式，认证成功后，认证信息都是存在服务器的Session里面的，浏览器的每次请求服务器都会去浏览器的cookie里面检查JSESSIONID是否存在，如果不存在，就会在服务器上去新建一个SESSION，新建的SESSIONID就会存到Cookie里面，这样用户每次发请求的时候都会通过JESSIONID找到相应的SESSION，这是目前基于服务器SESSION保存用户登录信息的一种方式。

但是当前后端分离过后，前端的资源html就不再和应用服务放在一台服务器上了，而是单独放在一台服务器上面，这样用户的请求都是发往Web Server,再由Web Server将请求发往后端。

用户不再通过浏览器直接访问后端的应用，而是通过其他的应用访问后端的应用。如果还想要之前的那种方式 cookie session来保存用户的信息，就会出现问题，比如开发繁琐，安全性和客户体验差，认证都是服务器自己做的，只有cookie里面有sessionId.那么服务器就会认为你已经登录了。如果别人知道了sessionID,那就不安全了。还有就是有些小程序的前端不支持cookie。

由于存在以上的问题，当我们请求不再是来自浏览器，而是一些应用的时候，我们应该用另外的方式来处理，这种方式就是令牌。

这样后端服务器也不必再把用户的认证信息放到session里面，而是通过令牌来验。也就是说应用服务器的授权不再是基于Sesion了，而是基于令牌。基于服务器SESSION来认证的话。这个SESSION都是由服务器自动完成的，后端没有办法干预。而基于token的这种形式，TOKEN怎么生成 包含什么信息，怎么校验都是可以控制的。比如之前说的安全性问题，这里可以将token的超时时间设置小一点，token 失效后可以通过token刷新的机制来保证用户不会重新登陆，走完oauth流程以后会给你一个refresh_token，而基于SESSION的，一旦session失效，就会让用户重新登陆。

那么Spring Social 和Spring Security Oauth之间有什么区别呢？

Spring Social 封装了第三方应用Client他所要做的大部分事情，去连任意一个我想连的服务提供商，而Spring Securiy Oauth则是封装了服务提供商所要完成的大部分行为，使用它就可以完成的搭建一个服务提供商，往外发令牌，验令牌。

2.Spring Security Oauth

 先要利用Spring Security Oauth实现服务提供商，需要封装两个内容，一个是认证服务器，一个资源服务器，在认证服务器中就有四种授权码模式，这几种授权的模式Spring Security Oauth都替我们实现好了，通过四种的授权模式我们知道了用户权限和他的身份之后就要生成token去存储，而token的生成和存储在oauth协议中并没有按照一个明确的规则去说明，但是Spring Security Oauth也做了一个标准的实现。

接着就是资源服务器，资源服务器是需要受到保护的，那么之前我们是如何做保护的呢？靠的是Spring Security 的过滤器链，那么在Sping Security Oauth中其实就是在这个过滤器链上又加了一个Oauth2AuthenticationProcessingFilter过滤器来实现的。

这个过滤器的作用就是从请求中拿出你发出去的token,根据配置的存储策略去存储里找到用户信息，根据用户信息来判断是否有权限等等。是否能访问资源等等。

还有一个问题就是，当我们用第三方登录，或者使用短信验证码来登录的时候，是不需要使用4种模式来生成Token的，那么需要自定义的认证模式，让短信登录，三方登录也能发生成token存储啊之类的。

 

3.实现标准的Oauth服务提供商

   oauth协议的说明地址：https://tools.ietf.org/html/rfc6749

    之前说过Spring Security Oauth已经实现