如何实现一个标准的OAuth服务提供商——通过OAuth2协议提供的4种授权模式获取token

一、Session与Token使用之传统架构模式与前后端分离架构模式对比

1、传统的应用架构方式，将用户信息保存在服务器session中，用户访问时，通过cookie中存放的sessionId访问应用服务器，从而来获取用户信息，见图(1)

图（1）

2、随着技术的不断升级发展，新颖的前端技术出现，如app或者前后端分离的架构方式，用户现在不是直接通过浏览器访问应用服务器，而是通过第三方应用（如APP、WebServer【如Node.js环境】，此时的第三方应用就是我们使用前后分离编写的前端应用）去访问应用服务器，如图(2)。这种架构下使用cookie、session的方式会出现一些问题。

图(2)

问题1：开发繁琐，cookie是浏览器内建好的，但是在app这种架构下需要自己处理cookie相关逻辑

问题2：安全性和客户体验差 发送一个请求，如果cookie里面有JSsesionId，我直接就从session里面获取信息了，就认为你登录了；此时如果的你的JSessionId别人知道了，放到cookie中去发请求就可以获取到用户信息了。这样一来就不安全了，如果把session过期时间设置变短，用户体验又变差了 但是使用token的方式，我们可以增强token字符串的复杂度 还可以将token的过期时间设置较短使用刷新token来保证安全性和客户体验性

问题3：有些前端技术不支持cookie，如小程序

由于这些问题，App、前后端分离这种架构模式下采用token（令牌）的方式存放用户的认证信息 也就是说认证、授权的方式不再是基于应用服务器的session了，而是基于token

3、Spring Security OAuth框架引入，主要实现了一个服务提供商(provider)的角色，包括认证服务器和资源服务器,见图(3)