客戶端必須得到使用者的授權（authorization grant），才能獲得令牌（access token）。
oauth 2.0定義了五種授權方式：
通過客戶端的後台伺服器，與"服務提供商"的認證伺服器進行互動。
（a）使用者訪問客戶端，後者將前者導向認證伺服器（乙個獲取授權的頁面）。
（b）使用者選擇是否給予客戶端授權。
（c）假設使用者給予授權，認證伺服器將使用者導向客戶端事先指定的"重定向uri"（redirection uri），同時附上乙個授權碼。
（d）客戶端收到授權碼，附上早先的"重定向uri"，向認證伺服器申請令牌。這一步是在客戶端的後台的伺服器上完成的，對使用者不可見。
（e）認證伺服器核對了授權碼和重定向uri，確認無誤後，向客戶端傳送訪問令牌（access token）和更新令牌（refresh token）。
這種模式常用於第三方認證登入。
樣例：a步驟中 get /oauth/authorize?response_type=code&client_id=【client_id】&redirect_uri=
引數說明：
客戶端的重定向位址接收到引數後執行步驟d
d步驟中 /oauth/token?client_id=【client_id】&grant_type=authorization_code&redirect_uri=
引數說明：
簡化模式（implicit grant type）不通過第三方應用程式的伺服器，直接在瀏覽器中向認證伺服器申請令牌，跳過了"授權碼"這個步驟，因此得名。所有步驟在瀏覽器中完成，令牌對訪問者是可見的，且客戶端不需要認證。
步驟如下：
（a）客戶端將使用者導向認證伺服器。
（b）使用者決定是否給於客戶端授權。
（c）假設使用者給予授權，認證伺服器將使用者導向客戶端指定的"重定向uri"，並在uri的hash部分包含了訪問令牌。
（d）瀏覽器向資源伺服器發出請求，其中不包括上一步收到的hash值。
（e）資源伺服器返回乙個網頁，其中包含的**可以獲取hash值中的令牌。
（f）瀏覽器執行上一步獲得的指令碼，提取出令牌。
（g）瀏覽器將令牌發給客戶端。
樣例：a步驟中，客戶端發出的http請求
樣例：a步驟中 get /oauth/authorize?response_type=【code】&client_id=【client_id】&redirect_uri=【redirect_uri】&state=【userid】
，包含以下引數：
access_token：表示訪問令牌，必選項。
token_type：表示令牌型別，該值大小寫不敏感，必選項。
expires_in：表示過期時間，單位為秒。如果省略該引數，必須其他方式設定過期時間。
scope：表示許可權範圍，如果與客戶端申請的範圍一致，此項可省略。
state：如果客戶端的請求中包含這個引數，認證伺服器的回應也必須一模一樣包含這個引數。
密碼模式（resource owner password credentials grant）中，使用者向客戶端（瀏覽器）提供自己的使用者名稱和密碼。客戶端（瀏覽器）使用這些資訊，向"服務商提供商"索要授權。
在這種模式中，使用者必須把自己的密碼給客戶端，但是客戶端不得儲存密碼。這通常用在使用者對客戶端高度信任的情況下，比如客戶端是作業系統的一部分，或者由乙個可信任公司提供。而認證伺服器只有在其他授權模式無法執行的情況下，才能考慮使用這種模式。
步驟如下：
（a）使用者向客戶端提供使用者名稱和密碼。
（b）客戶端將使用者名稱和密碼發給認證伺服器，向後者請求令牌。
（c）認證伺服器確認無誤後，向客戶端提供訪問令牌。
樣例：b步驟中，客戶端發出的http請求，包含以下引數：
客戶端模式（client credentials grant）指客戶端以自己的名義，而不是以使用者的名義，向"服務提供商"進行認證。嚴格地說，客戶端模式並不屬於oauth框架所要解決的問題。在這種模式中，使用者直接向客戶端註冊，客戶端以自己的名義要求"服務提供商"提供服務，其實不存在授權問題。
常用於訪問公共資源（無需登入）：**首頁
該模式沒有refresh_token,過期可以直接認證獲取匿名令牌。
步驟如下：
（a）客戶端向認證伺服器進行身份認證，並要求乙個訪問令牌。
（b）認證伺服器確認無誤後，向客戶端提供訪問令牌。
a步驟中，客戶端發出的http請求，包含以下引數：
擴充套件模式，是一種自定義模式。規範中僅對「grant type」引數提出了須為uri的要求。對於其他申請資料，可以根據需求進行自定義。
這裡不做研究。
當訪問令牌過期時候，重新整理重新獲取令牌。
客戶端發出更新令牌的http請求，包含以下引數：
OAuth學習筆記
oauth認證授權具有以下特點 在認證和授權的過程中涉及的三方包括 使用者 user 存放在服務提供方的受保護的資源的擁有者。客戶端 consumer 要訪問服務提供方資源的第三方應用，通常是 如提供 列印服務的 在認證過程之前，客戶端要向服務提供者申請客戶端標識。使用oauth進行認證和授權的過程...
OAuth2 0的四種授權模式
案例github自取 第二步 應用頁面那種這個資訊去認證伺服器授權 第三步 認證伺服器授權通過，拿到token，訪問真正的資源頁面 優點 不需要多次請求 額外開銷，同時可以獲取更多的使用者資訊。都拿到賬號密碼了 缺點 侷限性，認證伺服器和應用方必須有超高的信賴。比如親兄弟？應用場景 自家公司搭建的認...
OAuth2 0的四種授權模式
目錄隱式授權模式 implicit grant 授權碼授權模式 authorization code grant 密碼模式 resource owner password credentials grant 客戶端憑證模式 client credentials grant 第二步 應用頁面那種這個資...