## 流程梳理  * 以演示環境為例  * 指定后端網關地址  * 切換到back-center的login.html  * 切換到auth-server的源碼  * 切換到auth-server的配置  * 票據 redis持久化  * 接收前端請求，分配token  * 認證登錄后，用戶信息存儲在redis中   * 以訪問用戶中心為例(其他業務中心都是此套邏輯) * 前端攜帶access_token  * fiddler抓包  * 后端用戶中心必須引入  * 后端用戶中心的配置  * 票據 redis校驗機制  * 這樣通過uaa-client-spring-boot-starter中的一下流程  * 完成驗證token有效性處理 * 再通過  * 完成驗證權限標識符 ## Spring Security Oauth基本設計  * 訪問者(Accessor)需要訪問某個資源(Resource)是這個場景最原始的需求，但并不是誰都可以訪問資源，也不是任何資源都允許任何人來訪問，所以中間我們要加入一些檢查和防護 * 在訪問資源的所經之路上，可能遇到細菌，病毒，不管怎么樣，對于要防護的資源來說最好的方法就是設關卡點，對于上圖的FilterSecurityInvation,MethodIncation,Jointpoint,這些在spring security oauth中統稱SecuredObjects * 我們知道在哪里設置關卡點最合適，下一步就是設置關卡，對應FileSecurityInterceptor,MethodSecurityInterceptor,AspectSecurityInterceptor, 這些關卡統一的抽象類是AbstractSecurityInterceptor * 有關卡點，關卡了以后，到底誰該攔截誰不應該呢，spring security oauth中由 AccessDecisionManager控制 * 最后一個問題，這個誰怎么定義，我們總得知道當前這個訪問者是誰才能告訴AccessDecisionManager攔截還是放行，在spring security oauth框架中AuthenticationManager將解決訪問者身份認證問題，只有確定你在冊了，才可以給授權訪問。AuthenticationManager，AccessDecisionManager，AbstractSecurityInterceptor屬于spring security框架的基礎鐵三角。 * 有了以上骨架，真正執行防護任務的其實是SecurityFilterChain中定于的一系列Filter，其中ExceptionTranslationFilter,它負責接待或者送客，如果訪問者來訪，對方沒有報上名來，那么，它就會讓訪客去登記認證(找AuthenticationManager做認證)，如果對方報上名了，但認證失敗，那么請重新認證送客，送客的方式是拋出相應的Exception,所以名字叫做ExceptionTranslationFilter。 * 最后，這個filter序列中可能不滿足我們的需求，比如增加驗證碼，所以我們需要在其中穿插自己的Filter實現類，為定制和擴展Spring Security Oauth的防護體系。 * spring security內置的filter序列  * 執行過濾鏈