使用Redis来存储OAuth2相关的客户端信息以及生成的AccessToken是一个不错的选择，Redis与生俱来的的高效率、集群部署是比较出色的功能，如果用来作为服务认证中心的数据存储，可以大大的提高响应效率。

Redis还支持超时自动删除功能，OAuth2所生成的AccessToken相关的数据在超过配置的有效时间后就会自动被清除，这样也隐形的提高了接口的安全性。

既然Redis可以做到这么好，我们该怎么实现代码逻辑呢？

OAuth2所生成的AccessToken以及RefreshToken都存在过期时间，当在有效期内才可以拿来作为会话身份发起请求，否者认证中心会直接拦截无效请求提示已过期，那么我们怎么修改这个过期时间来满足我们的业务场景呢？

OAuth2默认的AccessToken是由DefaultAccessTokenConverter生成，是具有唯一性的UUID随机字符串，我们如果想要使用JWT来格式化AccessToken就需要使用JwtAccessTokenConverter来进行格式化，当然如果你有自己独特的业务可以自己实现AccessTokenConverter接口，并将实现类交付给IOC托管即可。

当我们整合了Spring Security以及OAuth2后发现，有一些业务请求是需要开放的，因为种种原因这时访问者还没有身份标识（比如：用户刚来，还没有注册，需要进行新用户注册，这时注册业务相关的接口都应该是开放的），下面我们来看看ApiBoot是怎么排除路径不进行权限拦截的。

Spring提供的原生的OAuth2依赖内置了几种比较常用的授权方式：password、authorization-code、client_credentials、refresh_token、implicit等，虽然可以满足我们日常的需求，不过针对一些特殊的需求还是捉襟见肘，有点无奈，比如：微信登录、短信登录…，针对这一点ApiBoot通过修改Spring OAuth2依赖的源码，可以根据业务进行自定义添加grantType。

SpringSecurity整合OAuth2是开发者公认的资源保护、服务认证的最佳搭配伙伴，这对好基友一直在默默的守护着应用服务的安全，根据访问者的不同角色可以颗粒度控制到具体的接口，从而实现权限的细微划分。

ApiBoot Security内部提供了两种方式进行读取需要认证的用户信息，在之前的文章中讲到过ApiBoot Security使用内存方式（memory）不写一行代码就可以实现用户的认证并获取AccessToken，那我们使用JDBC方式是不是也是这么的简单呢？