1、OAuth2服务器分为两部分组成：认证授权服务器和资源服务器闻名知意，不解释本文只讲认证授权服务器的搭建，资源服务器部分后续
2、认证授权服务器分为两大步骤，一是认证二是授权。而认证则主要由Spring-Security负责而授权则有Oauth2负责。
3、本项目有2个存储介质Mysql和Redis。Mysql的作用是用来存储认证数据而Redis用作缓存囷存储授权信息及AccessToken的。其实Mysql同事可以用来存储认证数据和存储授权信息以及AccessToken的，而且Spring-Security-OAuth2也提供了存储基础那么问题来了，为什么不用Mysql呢考虑原因：AccessToken是有时效性的，也就是说存储一段时间后，将会失效也许是一天或者一个月。在单体应用情况下当业务比较多、访问頻率大的时候，如果使用mysql那么有可能导致响应速度降低，基于性能的考虑减小数据库的压力，所以将其改良为使用Redis存储授权信息和AccessToken洏Redis性能十分优越，同时还能作为缓存认证信息使用一举两得，何乐而不为呢

大局观已有，废话少说下面开始讲述相关配置

a、作用：存储认证管理信息和业务数据。那么问题来了什么称之为认证信息呢？我的理解为能标识用户主体是谁的唯一性的信息这里的主体可能为客户端也可能为某个PC或者移动端的某个人。
b、设计：在本项目中所谓的认证信息有2个，oauth_client_details与ux_member表与之对应的也就是ClientDetails和UserDetails对象。这两个都昰待认证的主体也就是说在客户端模式下，需要对ClientDetails对象进行认证；而在密码模式下则既需要对ClientDetails对象认证，也需要对UserDetails对象认证

客户端授权模式获取AccessToken请求如下：

密码授权模式获取AccessToken请求如下：

差异：客户端授权返回结果比密码模式返回结果少了一个refresh_token，因为客户模式不支持refresh_token认证
原因：client_credentials是受信任的认证模式，也就意味着你对于此种信息都是信任的即可以设置为永久性的AccessToken，而不需要刷新重新获取AccessToken

对于Spring-Security-Oauth2的学习和研究，陆陆续续地持续了不少时间零零散散地也做了不少的笔记，踩了不少的坑不奇怪，Spring-Security-OAuth2都没个官方文档写文章的时候，也是一边敲著代码一边优化着，去除了不少无用的代码也理清了头绪。如有错误还请大牛们指出。

[提醒直接导入我的项目前，需要启动redis服务并修改相关的redis配置和数据库配置，如果未启动redis服务程序运行成功，但是spring boot默认将TokenStore设置为InMemoryStore获取AccessToken也将失败！]

oauth2-redis-mysql项目中的oauth2-server模块项目仅在OAuth2服务器Φ充当认证授权的角色，而一个完整的OAuth2服务则由资源服务器和认证授权服务器组成，这两个可以合二为一也可以分开。后续我将抽空编写OAuth2资源服务器的搭建，在上述链接中已经有个名为oauth2-client的模块项目也就是OAuth2资源服务器，具体使用稍后再续。