> OAuth（開放授權）是一個開放標準，允許用戶讓第三方應用訪問該用戶在某一網站上存儲的私密的資源（如基本消息，照片，聯系人列表），而無需將**用戶名**和**密碼**提供給第三方應用，使得自己的所有資源暴露給第三方應用。 # 1. 應用場景 ## 1.1 第三方授權登錄 用戶借助微信認證登錄黑馬程序員網站，用戶就不用單獨在黑馬程序員注冊用戶，怎么樣算認證成功嗎？黑馬程序 員網站需要成功從微信獲取用戶的身份信息則認為用戶認證成功，那如何從微信獲取用戶的身份信息？用戶信息的 擁有者是用戶本人，微信需要經過用戶的同意方可為黑馬程序員網站生成令牌，黑馬程序員網站拿此令牌方可從微 信獲取用戶的信息。 * 1、 客戶端請求第三方授權 用戶進入黑馬程序的登錄頁面，點擊微信的圖標以微信賬號登錄系統，用戶是自己在微信里信息的資源擁有者。 點擊“微信”出現一個二維碼，此時用戶掃描二維碼，開始給黑馬程序員授權。 * 2、 資源擁有者同意給客戶端授權 資源擁有者掃描二維碼表示資源擁有者同意給客戶端授權，微信會對資源擁有者的身份進行驗證， 驗證通過后，微信會詢問用戶是否給授權黑馬程序員訪問自己的微信數據，用戶點擊“確認登錄”表示同意授權，微信認證服務器會頒發一個授權碼，并重定向到黑馬程序員的網站。 * 3、 客戶端獲取到授權碼，請求認證服務器申請令牌 此過程用戶看不到，客戶端應用程序請求認證服務器，請求攜帶授權碼。 * 4、認證服務器向客戶端響應令牌 微信認證服務器驗證了客戶端請求的授權碼，如果合法則給客戶端頒發令牌，令牌是客戶端訪問資源的通行證。 此交互過程用戶看不到，當客戶端拿到令牌后，用戶在黑馬程序員看到已經登錄成功。 * 5、客戶端請求資源服務器的資源 客戶端攜帶令牌訪問資源服務器的資源。 黑馬程序員網站攜帶令牌請求訪問微信服務器獲取用戶的基本信息。 * 6、資源服務器返回受保護資源 資源服務器校驗令牌的合法性，如果合法則向用戶響應資源信息內容。 **OAauth2.0包括以下角色：** **1、客戶端（黑馬）** 本身不存儲資源，需要通過資源擁有者的授權去請求資源服務器的資源，比如：`Android`客戶端、`Web`客戶端（瀏覽器端）、微信客戶端等。 **2、資源擁有者（用戶）** 通常為用戶，也可以是應用程序，即該資源的擁有者。 **3、授權服務器（也稱認證服務器，微信認證服務）** 用于服務提供商對資源擁有的身份進行認證、對訪問資源進行授權，認證成功后會給客戶端發放令牌 （`access_token`），作為客戶端訪問資源服務器的憑據。本例為微信的認證服務器。 **4、資源服務器（微信服務）** 存儲資源的服務器，本例子為微信存儲的用戶信息。 現在還有一個問題，服務提供商能允許隨便一個客戶端就接入到它的授權服務器嗎？答案是否定的，服務提供商會 給準入的接入方一個身份，用于接入時的憑據: `client_id`：客戶端標識 `client_secret`：客戶端秘鑰 因此，準確來說，授權服務器對兩種`OAuth2.0`中的兩個角色進行認證授權，分別是資源擁有者、客戶端。 我們要做的就是將這兩者進行連接起來 先到第三方平臺資質審核，審核通過后（client_id,client_secret），用戶去第三方平臺授權登錄后，就可以獲取用戶基本信息，完成登陸。 ## **1.2 oauth四種模式** 根據場景不同，oauth有四種模式 ### **1.2.1 授權碼模式** #### 流程 > 說明：【A服務客戶端】需要用到【B服務資源服務】中的資源 **第一步**：【A服務客戶端】將用戶自動導航到【B服務認證服務】，這一步用戶需要提供一個回調地址，以備【B服務認證服務】返回授權碼使用。 **第二步**：用戶點擊授權按鈕表示讓【A服務客戶端】使用【B服務資源服務】，這一步需要用戶登錄B服務，也就是說用戶要事先具有B服務的使用權限。 **第三步**：【B服務認證服務】生成授權碼，授權碼將通過第一步提供的回調地址，返回給【A服務客戶端】。 > 注意這個授權碼并非通行【B服務資源服務】的通行憑證。 **第四步**：【A服務認證服務】攜帶上一步得到的授權碼向【B服務認證服務】發送請求，獲取通行憑證`token`。 **第五步**：【B服務認證服務】給【A服務認證服務】返回令牌`token`和更新令牌`refresh token`。 #### 使用場景 授權碼模式是`OAuth2`中最安全最完善的一種模式，應用場景最廣泛，可以實現服務之間的調用，常見的微信，QQ等第三方登錄也可采用這種方式實現。 ### **1.2.2 password模式** 1. client端自己本身有一套用戶體系，在認證時需要帶上自己的用戶名和密碼，以及客戶端的client\_id,client\_secret。 2. accessToken所包含的權限是用戶本身的權限，而不是客戶端的權限。 3. 如果你的系統已經有了一套用戶體系，每個用戶也有了一定的權限，可以采用password模式；如果僅僅是接口的對接，不考慮用戶，則可以使用client模式。 4. 不支持刷新token #### 流程 **第一步**：直接告訴【A服務客戶端】自己的【B服務認證服務】的用戶名和密碼 **第二步**：【A服務客戶端】攜帶【B服務認證服務】的用戶名和密碼向【B服務認證服務】發起請求獲取 `token`。 **第三步**：【B服務認證服務】給【A服務客戶端】頒發`token`。 ### 1.2.3 簡化模式（implicit） #### 流程 > 說明：簡化模式中沒有【A服務認證服務】這一部分，全部有【A服務客戶端】與B服務交互，整個過程不再有授權碼，token直接暴露在瀏覽器。 **第一步**：【A服務客戶端】將用戶自動導航到【B服務認證服務】，這一步用戶需要提供一個回調地址，以備【B服務認證服務】返回`token`使用，還會攜帶一個【A服務客戶端】的狀態標識`state`。 **第二步**：用戶點擊授權按鈕表示讓【A服務客戶端】使用【B服務資源服務】，這一步需要用戶登錄B服務，也就是說用戶要事先具有B服務的使用權限。 **第三步**：【 B服務認證服務】生成通行令牌`token`，`token`將通過第一步提供的回調地址，返回給【A服務客戶端】。 #### 使用場景 適用于A服務沒有服務器的情況。比如：純手機小程序，`JavaScript`語言實現的網頁插件等。 ### 1.2.4 client模式 #### 流程 > 仍需要client_id和secret > 說明：這種模式其實已經不太屬于`OAuth2`的范疇了。A服務完全脫離用戶，以自己的身份去向B服務索取`token`。換言之，用戶無需具備B服務的使用權也可以。完全是A服務與B服務內部的交互，與用戶無關了。 **第一步**：A服務向B服務索取`token`。 **第二步**：B服務返回`token`給A服務。 #### 使用場景 A服務本身需要B服務資源，與用戶無關。 ## client配置