OAuth2.0
OAuth 引入了一個授權層，用來分離兩種不同的角色：客戶端和資源所有者。客戶端來申請資源，資源所有者同意以后，資源服務器可以向客戶端頒發令牌。客戶端通過令牌，去請求數據。也就是說，OAuth 的核心就是向第三方應用頒發令牌。而且，OAuth 2.0 規定了四種獲得令牌的流程。你可以選擇最適合自己的那一種，向第三方應用頒發令牌。
具體的OAuth學習建議仔細研讀阮一峰的教程，
下面我們來使用spring cloud security 和 spring cloud oauth2兩個組件來簡單實現授權流程。
授權服務
下面我們來使用spring cloud security 實現一個授權服務，首先來引入依賴：
除了一個web組件，只引入了一個spring-cloud-starter-oauth2，這是因為spring cloud下的oauth2組件已經包含了security：
首先寫一個正常的登錄功能，application配置文件和啟動類都不用增加特殊配置，主要來配置security配置類：
這里面基本沒有特殊的配置，都是前面遇到過的熟悉的配置。有了這個配置類，基本的登錄功能就有了，要想有授權功能，還需要一個授權配置類，授權配置類需要繼承 AuthorizationServerConfigurerAdapter 類，並引入 @EnableAuthorizationServer 注解：
首先配置一個客戶端：
然后配置token的存儲和管理，此處使用secret作為秘鑰，后面會介紹使用非對稱加密的方式 ：
上面的token存儲在了內存中，token也可以存儲在數據庫或者redis中。最后配置授權端點的訪問控制：
以上就是一個簡答的授權服務。
資源服務
下面來搭建一個資源服務，其實授權和資源服務是可以合二為一的，此處為了清晰，將它們分開。pom中引入的依賴和授權服務是一樣的，同樣，配置文件和啟動類不需要做特殊配置。首先來寫兩個簡單的接口，一個定義為受保護，另一個不受保護：
然后定義一個資源服務配置類，需要繼承 ResourceServerConfigurerAdapter 類，並引入 @EnableResourceServer 注解：
首先來看令牌驗證的配置：
然后來看接口資源的攔截規則：
save開頭的可以直接訪問，不會被攔截，/user/save接口會被驗證。
注意上面配置的clientId和secret都是單一的配置死的，如果需要對多客戶端動態進行認真，需要重寫，后面是通過http調用的方式解析訪問令牌（主要是通過訪問授權服務的/oauth/check_token解析）。
測試
我們來根據前面說到的流程測試，首先向授權服務申請一個授權碼：
訪問首先會跳轉到登錄頁面：
輸入配置中默認的用戶名密碼登錄，然后進入下一個頁面：
這個頁面是真正的授權頁面，選擇Approve，點擊按鈕，同意授權，授權碼會通過回調地址獲取，如下圖：
然后攜帶授權碼申請訪問令牌，需要訪問下面的地址（需要使用post方式）：
將授權碼替換上面地址中的授權碼三個字，然后在postman中訪問：
其返回結果中，包含access_token參數，就是我們需要的訪問令牌，token_type 參數說明了令牌的類型，一般類型為bearer或者refresh_token可以在訪問令牌過期后向授權服務申請新的令牌，expires_in參數是令牌的有效時間，單位是秒，圖中顯示默認是12個小時。令牌已經得到了，下面來訪問資源接口，首先試一下不受保護的資源：
可以看到直接就能訪問，然后訪問受保護的資源接口：
得到這樣的結果說明該接口需要認證，我們來使用我們前面得到的令牌來訪問，首先選擇正確的認真協議：
然后在右側填寫前面獲取的access_token:
然后訪問接口，就能看到受保護的資源通過令牌可以訪問：
代碼地址 ： https://gitee.com/blueses/spring-boot-security 15 和 16