一、什么是OAuth協議
OAuth 協議為用戶資源的授權提供了一個安全的、開放而又簡易的標準。與以往的授權方式不同之處是 OAuth的授權不會使第三方觸及到用戶的帳號信息（如用戶名與密碼），即第三方無需使用用戶的用戶名與密碼就可以申請獲得該用戶資源的授權，因此 OAuth是安全的。OAuth 是 Open Authorization 的簡寫。
OAuth 本身不存在一個標準的實現，后端開發者自己根據實際的需求和標準的規定實現。其步驟一般如下：
- 客戶端要求用戶給予授權
- 用戶同意給予授權
- 根據上一步獲得的授權，向認證服務器請求令牌（token）
- 認證服務器對授權進行認證，確認無誤后發放令牌
- 客戶端使用令牌向資源服務器請求資源
- 資源服務器使用令牌向認證服務器確認令牌的正確性，確認無誤后提供資源
二、OAuth2.0是為了解決什么問題？
任何身份認證，本質上都是基于對請求方的不信任所產生的。同時，請求方是信任被請求方的，例如用戶請求服務時，會信任服務方。
所以，身份認證就是為了解決身份的可信任問題。
在OAuth中，簡單來說有三方：用戶（這里是指屬于服務方的用戶）、服務方、第三方應用。
服務方不信任用戶，所以需要用戶提供密碼或其他可信憑據；
服務方不信任第三方，所以需要第三方提供自已交給它的憑據（通常的一些安全簽名之類的就是）；
用戶部分信任第三方，所以用戶愿意把自已在服務方里的某些服務交給第三方使用，但不愿意把自已在服務方的密碼交給第三方；
在oauth2.0的流程中，用戶登錄了第三方的系統后，會先跳去服務方獲取一次性用戶授權憑據，再跳回來把它交給第三方，第三方的服務器會把授權憑據以及服務方給它的的身份憑據一起交給服務方，這樣，服務方一可以確定第三方得到了用戶對此次服務的授權（根據用戶授權憑據），二可以確定第三方的身份是可以信任的（根據身份憑據），所以，最終的結果就是，第三方順利地從服務方獲取到了此次所請求的服務。
從上面的流程中可以看出，oauth2.0完整地解決掉了用戶、服務方、第三方 在某次服務時這三者之間的信任問題。
三、OAuth2.0成員
- Resource Owner（資源擁有者：用戶）
- Client （第三方接入平臺：請求者）
- Resource Server （服務器資源：數據中心）
- Authorization Server （認證服務器）
Oauth2.0基本流程：
原理很簡單，用戶訪問App，App訪問Authorization Server請求權限，
Authorization Server得到用戶同意后，返回token，
App通過這個token向Authorization Server索要數據，
App只能從Authorization Server這個中介獲取服務器數據，而無法直接訪問Resource Server。
四、第三方客戶端的授權模式
客戶端必須得到用戶的授權（authorization grant），才能獲得令牌（access token）。OAuth 2.0定義了四種授權方式。
- 授權碼模式（authorization code）
- 簡化模式（implicit）
- 密碼模式（resource owner password credentials）
- 客戶端模式（client credentials）
授權碼模式（authorization code）是功能最完整、流程最嚴密的授權模式。它的特點就是通過客戶端的后臺服務器，與"服務提供商"的認證服務器進行互動。
它的步驟如下：
- 用戶訪問客戶端，后者將前者導向認證服務器。
- 用戶選擇是否給予客戶端授權。
- 假設用戶給予授權，認證服務器將用戶導向客戶端事先指定的"重定向URI"（redirection URI），同時附上一個授權碼。
- 客戶端收到授權碼，附上早先的"重定向URI"，向認證服務器申請令牌。這一步是在客戶端的后臺的服務器上完成的，對用戶不可見。
- 認證服務器核對了授權碼和重定向URI，確認無誤后，向客戶端發送訪問令牌（access token）和更新令牌（refresh token）。
下面是上面這些步驟所需要的參數。
步驟1: 客戶端申請認證的URI，包含以下參數：
- response_type：表示授權類型，必選項，此處的值固定為"code"
- client_id：表示客戶端的ID，必選項。（如微信授權登錄，此ID是APPID）
- redirect_uri：表示重定向URI，可選項
- scope：表示申請的權限范圍，可選項 state：表示客戶端的當前狀態，可以指定任意值，認證服務器會原封不動地返回這個值。
例子:
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 HTTP/1.1 Host: server.example.com
對比微信網頁掃描授權請求CODE
https://open.weixin.qq.com/connect/qrconnect?appid=APPID&redirect_uri=REDIRECT_URI&response_type=code&scope=SCOPE&state=STATE#wechat_redirect
步驟3：服務器回應客戶端的URI，包含以下參數：
- code：表示授權碼，必選項。該碼的有效期應該很短，通常設為10分鐘，客戶端只能使用該碼一次，否則會被授權服務器拒絕。該碼與客戶端ID和重定向URI，是一一對應關系。
- state：如果客戶端的請求中包含這個參數，認證服務器的回應也必須一模一樣包含這個參數。
例子：
HTTP/1.1 302 Found Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA &state=xyz
步驟4：客戶端向認證服務器申請令牌的HTTP請求，包含以下參數：
- grant_type：表示使用的授權模式，必選項，此處的值固定為"authorization_code"。
- code：表示上一步獲得的授權碼，必選項。
- redirect_uri：表示重定向URI，必選項，且必須與A步驟中的該參數值保持一致。
- client_id：表示客戶端ID，必選項。
例子：
POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
步驟5：認證服務器發送的HTTP回復，包含以下參數：
- access_token：表示訪問令牌，必選項。
- token_type：表示令牌類型，該值大小寫不敏感，必選項，可以是bearer類型或mac類型。
- expires_in：表示過期時間，單位為秒。如果省略該參數，必須其他方式設置過期時間。
- refresh_token：表示更新令牌，用來獲取下一次的訪問令牌，可選項。
- scope：表示權限范圍，如果與客戶端申請的范圍一致，此項可省略。
例子：
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
從上面代碼可以看到，相關參數使用JSON格式發送（Content-Type: application/json）。此外，HTTP頭信息中明確指定不得緩存。
五、更新令牌
如果用戶訪問的時候，客戶端的"訪問令牌"已經過期，則需要使用"更新令牌"申請一個新的訪問令牌。客戶端發出更新令牌的HTTP請求，包含以下參數：
- granttype：表示使用的授權模式，此處的值固定為"refreshtoken"，必選項。
- refresh_token：表示早前收到的更新令牌，必選項。
- scope：表示申請的授權范圍，不可以超出上一次申請的范圍，如果省略該參數，則表示與上一次一致。
例子：
POST /token HTTP/1.1
Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
