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進行用戶認證（指用戶信息放在數據庫的情況）