1.使用場景
A系統存放着訂單信息
B系統需要查詢A系統中的訂單信息，但是必須要A系統驗證通過后，才能查詢。
此時，我們有兩種驗證方式：
1)擁有A系統的賬戶/密碼
弊端是對A系統來說，直接提供賬戶/密碼的方式非常不安全。
2)A系統給B系統頒發一個令牌，規定了令牌的使用范圍和有效期，可以理解為一個通行證。
第二種方式，就是我們所說的OAuth授權。
2.OAuth原理
我們稱待授權系統為“客戶端”，授權系統為“服務器”
OAuth的原理是，“客戶端”不能直接登錄“服務器”，“客戶端”登錄時，“服務端”有一個“授權層”，會首先檢驗頒發給“客戶端”的“令牌”是否有效，若有效，則允許登錄。
3.OAuth驗證流程
（A）客戶端請求用戶授權
（B）用戶同意授權給客戶端
（C）客戶端使用上一步獲得的授權，像服務器申請令牌
（D）服務器對客戶端進行認證后，確認無誤，同意發送令牌
（E）客戶端使用令牌，向服務器請求資源
（F）服務器確認令牌無誤，返回資源
上述步驟中，關鍵是用戶如何給客戶端授權。有了授權后，客戶端就可以獲得令牌，繼而獲得資源。
4.客戶端授權的四種模式
授權碼模式
簡化模式
密碼模式
客戶端模式
5.授權碼模式
（A）用戶訪問客戶端，客戶端將用戶導向服務器，包含了“重定向URI”地址
（B）用戶選擇是否給予客戶端授權
（C）若給予，服務器將用戶導向“重定向URI”地址，同時附上一個授權碼
（D）客戶端收到授權碼，附上“重定向URI”地址，向服務器申請令牌
（E）服務端核對授權碼和重定向URI，確認無誤，向客戶端發送訪問令牌和更新令牌
授權模式的特點是，需要通過客戶端服務器，來和服務器端進行交互。
6.簡化模式
簡化模式不需要客戶端服務器，直接通過瀏覽器向服務器申請令牌，跳過了“授權碼”
所有步驟在瀏覽器中完成，不需要認證客戶端。
（A）客戶端將用戶導向服務器
（B）用戶決定是否給予客戶端授權
（C）若授權，服務器將用戶導向客戶端指定的“重定向URI”，URI的hash部分包含了訪問令牌。
（D）瀏覽器向服務器發出請求，不包括上一步收到的hash值
（E）服務器返回一個網頁，其中包含的代碼可以獲取hash值中的令牌
（F）瀏覽器執行上一步獲得的腳本，提取出令牌
（G）瀏覽器將令牌發給客戶端
7.密碼模式
用戶向客戶端提供自己的用戶名和密碼，客戶端使用用戶名/密碼，向服務器索要授權
客戶端不得儲存密碼，通常是一些大品牌信譽好的公司，才用這種模式。
（A）用戶向客戶端提供用戶名/密碼
（B）客戶端講用戶名/密碼發給服務器，請求令牌
（C）服務器確認無誤，向客戶端提供訪問令牌
8.客戶端模式
客戶端以自己的名義，而不是用戶的名義，向服務器進行認證。用戶直接向客戶端注冊，客戶端以自己的名義要求服務器提供服務，其實不存在授權問題。
（A）客戶端向服務器進行身份認證，並要求一個訪問令牌
（B）服務器確認無誤，向客戶端提供訪問令牌
9.更新令牌
客戶端的訪問令牌過期后，需要使用更新令牌申請一個新的訪問令牌