基于服务器Session的认证方式：
前边说的用户名密码登录、短信登录、第三方登录，都是普通的登录，是基于服务器Session保存用户信息的登录方式。登录信息都是存在服务器的session（服务器的一块内存）里 ，用户通过浏览器访问服务的时候，每一次服务器都会检查浏览器的cookie里有没有JESSIONID，如果不存在JESSIONID服务器会新建一个session，将新建的session的id写到浏览器的cookie里。服务器每次都会从请求里拿出JSESSIONID，然后去找对应的session，然后从session里拿出用户信息。
app、前后端分离
随着技术的发展，新的前端渠道app出现了，而且随着应用部署方式的改变，前后端分离现在也很流行，前后端分离模式下，html就是一种前端的资源，不在和应用服务器部署在一起了，而是单独部署在WebServer上，比如nodejs。前后端分离模式用户访问的是WebServer，由WebServer访问Application Server，WebServer处理ajax请求和渲染返回的数据。这种模式下，访问应用服务器的不再是用户了而是第三方的应用。
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
明确一点，如果app和WebServer只要能处理cookie，这种模式还是可以用Cookie+Session认证方式的。但是存在问题：
1，开发繁琐：浏览器对cookie已经是内建好的，不需要我们针对cookie写太多代码。app而言，每次关闭再打开app，都需要实例化http客户端发请求，每次实例化http客户端cookie都是空的，需要自己去处理之前cookie存的数据。
2，安全性和客户体验差：cookie 没有特别的校验，JSESSIONID如果被泄露，放在cookie窃取到用户信息。如果通过缩短cookie有效时间解决这个问题，就会出现用户不断登录的情况
3，有些前端技术不支持cookie如微信小程序
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
令牌的方式处理认证信息的存储
发给用户一个令牌token，用户每次访问都拿着令牌，来判断用户登录信息权限等，token表现形式就是一个字符串。这样上边说的三个问题就可以解决了，token 不是通过cookie来携带的，而是http请求的参数，在请求头或者普通的参数都行；基于session的JESSIONID是服务器自己生成的，校验也是他自己校验，但是token的生成、校验我们可以自己控制，可以在token上加技术手段来增强安全性，可以实现token 刷新的方式而不会出现用户重复登录，缩短token有效时间增强安全性还保证了用户体验。
用令牌的方式在应用服务器和其他应用之间的认证和授权。这就很自然的联系到了OAuth协议了。OAuth协议就是用token的方式来做认证授权的：
前后端分离模式下使用OAuth2协议的结构
应用服务器--------------------相当于-------->服务提供商（如第三方登录的微信服务器）
APP、WebServer----------相当于-------->第三方应用
Spring Security OAuth 简介：
Spring Social 实际上是封装了第三方应用（Client）所要做的大多数事情，拿着Spring Social可以很快开发一个第三方应用来连接想要连接的服务提供商，而Spring Security OAuth和Spring Social 正好相反，Spring Security OAuth 封装了服务提供商的大部分行为，用来快速搭建服务提供商的程序，发放令牌、校验令牌。
要实现服务提供商，其实就是要实现两个服务器 ：认证服务器、资源服务器
认证服务器：
实现四种授权模式：来确认用户身份以及拥有的权限。Spring Security OAuth 里已实现了四种授权模式
token的生成和存储：根据信息生成令牌token，资源服务器根据token拿资源。OAuth协议没有规定token的具体生成方式，Spring Security OAuth 提供了默认的实现。
资源服务器：
保护资源，在我们的场景，资源就是Rest 服务。Spring Security 是一系列的过滤器链，Spring Security OAuth就是加了个OAuth2AuthenticationFilter的过滤器，从请求中拿出来发出去的token，根据配置的存储策略从存储里根据token拿出用户信息，根据用户信息是否存在、是否有权限等来判断是否能访问要访问的 服务。
自己实现服务提供商：
要处理的问题是，我们不希望用户走标准的四种授权模式的，如手机号+短信验证码登录方式和标准四种授权模式是对应不上的。我们需要做的是让自定义的认证方式可以嫁接到认证服务器上，让用户通过自己的认证方式也可以调用token 生成的机制生成token发给第三方应用，第三方应用存储这个token ，每次访问服务带上这个token 经过过滤器链上的过滤器通过认证、授权来访问服务。
1，实现一个标准的OAuth2协议中Provider（服务提供商：认证服务器、资源服务器）角色的主要功能
2，重构之前的认证方式，使其支持token
3，自定义 token的生成方式