我们之前实现的登录方式，登陆成功以后用户信息都是存在服务器Session中，把新建的SESSIONID再写到浏览器的Cookie，然而Cookie是浏览器独有的机制，对于APP或者小程序，Cookie+Session方式的登录流程就不适用了，那这时候该用什么方式呢？
登录认证流程对比
Cookie + Session方式登录流程
- 我们之前实现的登录方式，登陆成功以后用户信息都是存在服务器Session中，用户通过浏览器每次去访问服务的时候都会检查浏览器Cookie是否存在JSESSIONID，如果不存在就会在服务器上新建一个SESSION，把新建的SESSIONID写到浏览器的Cookie里，这样每次浏览器发请求的时候会
根据SESSIONID找到响应的Session，从里边取出用户信息。 - 图解：
Token方式认证流程
- 上面那种方式需要用到浏览器特有的Cookie，但是在很多情况下服务端并不是和浏览器交互，比如APP或者小程序甚至是前后端分离，在前后端分离情况下，浏览器先访问的其实是Web Server的资源，而不是直接访问的服务器，APP和小程序也是一样，
访问服务器的不再是浏览器了，所以Cookie+Session的方式并不适用。 - 其实要做到Cookie+Session方式也是可以的，但是会有几个问题：
-
开发繁琐，Cookie是浏览器独有的机制，想要APP也有类似机制就需要写更多代码去实现。 -
安全性和客户体验差，因为基于Cookie+Session的方式，认证方式都是服务器做的，其实也就只要根据Cookie中的SESSIONID去获取用户登录信息，这就导致了只要有SESSIONID就能够访问服务器接口，安全性方面很差；假如说为了提高安全性而把Session有效时间缩短，那用户就需要频繁去登录，客户体验上就差了。 - 有些前端技术
不支持Cookie，比如小程序。
-
- 于是，这里就需要用到一种Token令牌的认证方式，其实他和上面那种方式类似，也是需要给用户一个标识Token，只不过在Session方式下是往Cookie中去写JSESSIONID，令牌的方式直接给用户发一个Token，
用户每次访问的时候也要带上令牌，而应用服务器不再存储标识，服务器的认证不再基于Session而是基于令牌。 - 这种方式的好处：
-
开发简单，令牌的表现形式其实就是一个字符串，它传到后台只需要通过参数（请求头或者请求体均可）带到后台，而不需要专门去写Cookie的一些代码，所以开发起来简单。 -
安全性和客户体验，首先前种方式生成JSESSIONID是由服务器完成，我们没法干涉，但是对于后种方式，Token的生成可以包含什么信息，怎么去校验这些都是可以控制的，可以对Token增加很多技术手段增加安全性，比如缩短有效时间，同时加入刷新机制，即保证了安全性又不影响用户体验。 - 对于
不支持cookie的这种情况就不存在了。
-
- 图解：
Spring Security OAuth
OAuth协议
- 其实会发现Token认证方式就是OAuth协议服务提供商的一些操作，
Spring Security OAuth就封装了所有服务提供商的一些行为。 - OAuth协议流程图解：
Spring Security OAuth简介
- 图解说明：
-
服务提供商职责，服务提供商实际上就是实现认证服务器和资源服务器。在认证服务器中主要实现的是4种授权模式，通过四种授权模式让应用确认用户身份以及它所拥有的权限，然后根据这些授权信息进行Token的生成和存储。在资源服务器中就是保护资源（rest服务），其实就是之前一直在说的SpringSecurity过滤器链，而
Spring Security OAuth功能的实现就是在过滤器链中加了一个新的过滤器叫做OAuth2AuthenticationProcessingFilter，作用就是从请求中拿出携带的Token，根据之前配置的Token存储策略找到对应的用户信息，然后根据用户信息是否存在等等一系列判断来决定最终是否能访问到资源。 - 在我们实现的过程中，并不会去走四种授权模式，因为比如说短信验证码的方式，它和标准的四种授权模式搭不上太大关系，所以我们要做的事情就是
实现自定义的认证，让自定义的认证方式嫁接到认证服务器上去，在短信认证、用户名密码认证等之后也可以调用Token的生成机制生成Token发给第三方应用。 - 图解中绿色框的内容Spring Security都已经实现了，我们要写的就是橙色框中的东西。
OAuth2.0协议
- 关于OAuth2.0协议请参考：Spring Security（九）：OAuth2.0协议
- 上一篇：Spring Security（十一）：退出登录
- 下一篇：努力更新中…