目錄
OAuth
OAuth（Open Authorization，開放的授權協議）是一個安全的、開放而簡易的用戶資源授權協議。OAuth 協議有三大特徵：
- 安全：不會使第三方觸及到用戶的帳號信息（如：用戶名與密碼），即第三方無需使用用戶的用戶名與密碼就可以申請獲得該用戶資源的授權，因此 OAuth 是安全的。
- 開放：任何第三方都可以使用 OAuth 認證服務，任何服務提供商都可以實現自身的 OAuth 認證服務，因而 OAuth 是開放的。
- 簡單：業界提供了 OAuth 的多種實現，如：PHP、JavaScript，Java，Ruby 等各種編程語言的開發包，大大節約了程序員的時間，因而 OAuth 是簡易的。
互聯網很多服務，如：Open API，很多大公司，如：Google，Yahoo，Microsoft 等都提供了 OAuth 認證服務。
OAuth 緣起
舉一個典型案例：如果一個用戶需要兩項服務，圖片在線存儲服務 A、圖片在線打印服務 B。假設服務 A、服務 B 由兩家不同的服務提供商提供，所以用戶需要在這兩家服務提供商的網站上分別註冊兩個用戶名、密碼各不相同的賬戶。
當用戶要使用服務 B 打印存儲在服務 A 上的圖片時，用戶該如何處理？
-
方式 1：用戶先將圖片從服務 A 下載到本地，然後上傳到服務 B 上打印，這種方式安全但處理比較繁瑣，效率低下；
-
方式 2：用戶將在服務 A 上註冊的用戶名與密碼提供給服務 B，服務 B 使用用戶的帳號到服務 A 處下載待打印的圖片。這種方式的效率是提高了，但是安全性也大大降低了（服務 B 可以使用用戶的用戶名與密碼去服務 A 上查看甚至篡改用戶的資源）。
很多公司和個人都嘗試解決此類問題，包括：Google、Yahoo、Microsoft，這也促進了 OAuth 項目組的產生。OAuth 最終由 Blaine Cook、Chris Messina、Larry Halff 及 David Recordon 共同發起，目的在於爲 API 訪問授權提供一個開放的標準。
OAuth 規範的 1.0 版於 2007 年 12 月 4 日發佈與 IETF（國際互聯網工程任務組），編號是 RFC5849，標誌着 OAuth 正式成爲互聯網標準協議。
OAuth 原理
- Client：第三方應用（Third-party application）客戶端。
- Resource Owner：資源所有者。
- Authorization server：認證服務器，即服務提供商專門用來處理認證的服務器。
- Resource server：資源服務器，即服務提供商存放用戶生成的資源的服務器。它與認證服務器，可以是同一臺服務器，也可以是不同的服務器。
第三方應用登錄流程：
- 用戶打開第三方應用客戶端以後，客戶端要求用戶給予授權。
- 用戶同意給予客戶端授權。
- 客戶端使用上一步獲得的授權，向認證服務器申請令牌。
- 認證服務器對客戶端進行認證以後，確認無誤，同意發放令牌。
- 客戶端使用令牌，向資源服務器申請獲取資源。
- 資源服務器確認令牌無誤，同意向客戶端開放資源。
OAuth 在 Client 與 Resource server 之間設置了一個授權層（Authorization Layer）。Client 不能直接登錄 Resource server，只能登錄 Authorization server。上述步驟 2 是整個流程的關鍵，有了這個授權以後，客戶端就可以獲取令牌繼而憑令牌獲取資源。
令牌與密碼的區別
令牌（token）與密碼（password）都用於身份認證，但有三點差異：
- 令牌是短期的，到期會自動失效，用戶自己無法修改。密碼一般長期有效，用戶不修改，就不會發生變化。
- 令牌可以被數據所有者撤銷，但篡改後會立即失效。
- 令牌有權限範圍（scope），對於網絡服務來說，只讀令牌就比讀寫令牌更安全。密碼一般是完整權限。
OAuth2
OAuth2 是 OAuth1.0 的升級版本，但不向前兼容 OAuth1.0，即完全廢止了 OAuth1.0。2012 年 10 月，OAuth 2.0 協議正式發佈爲 RFC 6749。當下百度開放平臺，騰訊開放平臺等大部分的開放平臺都使用了 OAuth 2.0 協議。
OAuth2 的四種授權模式
- 授權碼（authorization-code）
- 隱藏式（implicit）
- 密碼式（password）：
- 客戶端憑證（client credentials）
授權碼
授權碼（authorization code）方式，指的是第三方應用先申請一個授權碼，然後再用該碼獲取令牌。
這種方式是最常用的流程，安全性也最高，它適用於那些有後端的 Web 應用。授權碼通過前端傳送，令牌則是儲存在後端，而且所有與資源服務器的通信都在後端完成。這樣的前後端分離，可以避免令牌泄漏。
舉例說明：我作爲一個用戶在使用網站 A，並希望通過網站 A 直接訪問 B 的資源，此時 B 會要求 A 提供我的用戶信息，例如：彈出 QQ 賬戶的登錄授權窗口。我把 QQ 賬戶登錄成功後，表示我答應了 A 可以訪問 B 中屬於我自身的資源。我向 B 證明了合法的身份後，B 同時向 A 發放了一個令牌（Token），A 拿着這個 Token 就可以有限的時間內訪問網站 B 中有限的資源。
隱藏式
有些 Web 應用是純前端應用，沒有後端。這時就不能用上面的方式了，必須將令牌儲存在前端。隱藏式授權，允許直接向前端頒發令牌。這種方式沒有授權碼這個中間步驟，所以稱爲 “授權碼隱藏式（implicit）”。
這種方式把令牌直接傳給前端，是很不安全的。因此，只能用於一些安全要求不高的場景，並且令牌的有效期必須非常短，通常就是會話期間（session）有效，瀏覽器關掉，令牌就失效了。
密碼式
如果你高度信任某個第三方應用，密碼式授權允許用戶把用戶名和密碼直接告訴該第三方應用。該應用就使用你的密碼，申請令牌，這種方式稱爲 “密碼式（password）”。
客戶端憑證
憑證式授權指客戶端以自己的名義，而不是以用戶的名義，向 “服務提供商” 進行認證。嚴格地說，客戶端模式並不屬於 OAuth 協議所要解決的問題。在這種模式中，用戶直接向客戶端註冊，客戶端以自己的名義要求 “服務提供商” 提供服務，其實不存在授權問題。
所以，憑證式授權僅僅適用於沒有前端的命令行應用，即在命令行下請求令牌。這種方式給出的令牌，是針對第三方應用的，而不是針對用戶的，即有可能多個用戶共享同一個令牌。
更新令牌
令牌的有效期到了，如果讓用戶重新走一遍上述的流程，用戶體驗必然不好。OAuth 2.0 允許用戶自動更新令牌。具體方法是：網站 B 頒發令牌的時候，一次性頒發兩個令牌，一個用於獲取數據，另一個用於獲取新的令牌（refresh token 字段）。令牌到期前，用戶使用 refresh token 發一個請求，去更新令牌。
https://b.com/oauth/token?
grant_type=refresh_token&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
refresh_token=REFRESH_TOKEN
上面 URL 中，grant_type 參數爲 refresh_token 表示：要求更新令牌。client_id 參數和 client_secret 參數用於確認身份。refresh_token 參數就是用於更新令牌的令牌。網站 B 驗證通過以後，就會頒發新的令牌。