一、獲取token過程
1、zuul，轉發請求到認證服務器，獲取token
2、
最後調到定義的redisTokenStore.getAccessToken返回token
Authenticaton對象
用前綴+name,clientid,scope MD5後組成key
10f0ad1bd4f6c7cb5744016a8a125f04
auth_to_access:10f0ad1bd4f6c7cb5744016a8a125f04
生成token:82c30174-b024-498d-b19d-053e4dd05e92
存儲到redis, key: access:82c30174-b024-498d-b19d-053e4dd05e92
獲取token的接口，不用走過濾器，是因爲：開始會匹配Url,
如果在以上的url中，那麼就會直接請求到對應的方法
二、用token認證過程
1、通過zull轉發，請求認證服務器actuator 端點，由於認證服務器對actuator端點有攔截配置，所以會走一個 fileter
這個fiter會去從requet中獲取到Authorization 請求頭，拿出裏面的token，然後再調用
Authentication authResult = authenticationManager.authenticate(authentication);
調這個方法校驗，
OAuth2Authentication auth = tokenServices.loadAuthentication(token);
OAuth2AccessToken accessToken = tokenStore.readAccessToken(accessTokenValue);
再調到我們重寫的tokenStore的方法，獲取accessToken
從redis中獲取token ，key爲： access:82c30174-b024-498d-b19d-053e4dd05e92
請求頭中需要帶上從第一步獲取的認證碼，token前面要帶上token的類型
三、微服務認證過程
1、請求zuul地址，會轉發到micro-web-security
2、mirco微服務會對user 開頭的請求路徑要求 auth認證，由於這它不是認證服務器，所以沒有配置 authManager 和 storeService
配置文件中配置了：security.oauth2.resource.user-info-uri=http://127.0.0.1:7070/auth/security/check
，當轉到micro-web-sercutiry微服務時， 會被outh2的過濾器攔截，然後找到 這個uer-info-uri 去調用這個接口 認證，這個是認證服務器的地址，會返回 Principl對象，如果獲取成功，那麼就會再執行自己的方法，如果失敗 則報錯。
再細想想，只配置這個地是否還不夠， 認證服務器 肯定會走過濾器，校驗客戶的合法性，於是還需要下面配置：
security.oauth2.resource.prefer-token-info=false
#security.oauth2.client.id=micro-web
security.oauth2.client.clientId=micro-web
security.oauth2.client.client-secret=123456
security.oauth2.client.access-token-uri=http://api-gateway/auth/oauth/token
security.oauth2.client.grant-type=client_credentials
security.oauth2.client.scope=all
請求的客戶端是誰，獲取token的地址，
認證服務器獲取到這些信息後，會拿這個客戶端生成的token 和 轉過來的token對比，如果相同證明是合法請求，說明 這個客戶端之前從認證服務器獲取過token