1、主要分析无session的情况下，即令牌模式，已经认证过的用户，如何进行资源访问控制，其原理与spring security类似，但是不同的是spring security不对令牌进行处理。
2、spring security第一次认证通过后，需要手动生成令牌，第二次访问，也需要自己编写过滤器手动解析令牌，并且需要手动通过SecurityContextHolder进行认证上下文设置，这种方式比较灵活。
3、对于spring-cloud-starter-oauth2有所不同，令牌是由系统生成，也由系统解析，当然它提提供了可重写的接口
但是，它写的真的和spring security不是一个级别的，
其中有个硬编码，判断map中是否有"user_name"，而不是"username",之前oath2各种判断用的都是"username"，到二次过滤时突然换成"user_name"，导致userAuthentication一直为null，
所以我怀疑这两个安全模块不是一波人写的，spring官方也在2020年也发布迁移计划，即将从Spring Security OAuth 2.x 到 Spring Security 5.2.x的迁移。我猜他们同时并行两个安全框架也是心中一千个CNM。
4、对于spring-cloud-starter-oauth2源码跟踪，应该从OAuth2AuthenticationProcessingFilter过滤器开始，
其中关键步骤是Authentication authResult = authenticationManager.authenticate(authentication)真是熟悉的配方，可惜到后面就有点不行了。
5、源码中UserAuthenticationConverter接口里硬编码是是否能生成userAuthentication的关键。
final String USERNAME = "user_name";
6、要么就是自定义令牌转换器的时候塞一个"user_name",要么自己写个过滤器重新生成一个Authencation，两种方式都是解决userAuthentication为null的问题。
7、为啥userAuthentication为null的时候spring-cloud-starter-oauth2的二次访问安全上下文没有问题呢？
因为spring-cloud-starter-oauth2重点在于判断客户端id和密钥，认为有这两个就ok，这是指认证以后，二次带token访问的情况。
8、补充spring-cloud-starter-oauth2认证模式中密码模式：经过两次认证，分别对客户端和用户进行认证
客户端认证：首先通过BasicAuthenticationFilter使用HttpBasic认证，完成进入用户认证
用户认证： 然后通过根据重写UserDetailService实现类通过DaoAuthenticationProvider进行用户认证（指用户信息放在数据库的情况）