小朱® 的技術隨手寫

OAuth，一個讓人又愛又恨的驗證協定，它讓許多主流的社群網站與網路服務打開了封閉已久的驗證大門，它也是在網路上公開個人或私人資訊 (private data) 前最主要的驗證管道之一，重要的是，在這個協定下，所有公開給外界的私密資料會受到兩個階段的保護，OAuth 保障使用者可以在應用程式要求資料前由使用者做明確授權，只有授權過的資源才會開放給應用程式存取用，而且 OAuth 公開的特性，可以讓應用程式在極少量程式碼的變更下，移植到不同的服務繼續使用，而 OAuth 協定也讓服務端精確的控制要開放的服務，並且提供使用者授權的管道以讓使用者能自由控制授權與否，而且用戶端應用程式只要利用 HTTP 協定即可使用 OAuth 服務。那為什麼我會說又愛又恨呢？因為它真的不容易使用，會讓想使用它的開發人員頭髮被抓掉好幾百根…。

OAuth 是 Open Authorization 的縮寫，由 2006 年起草的新驗證規格，當時產業界還有一些不同的協定，像是 Open ID，Shibboleth，WS-Federation 等協定，這些都被稱為 Central Authentication Service (中央驗證服務)，只是這些協定使用上都不怎麼容易，有些有明確的軟體平台限制，有些則是要裝某些套件等，OAuth 則是比較後期出現的服務，但它用起來簡單，又相容於 HTTP 的標準，任何可以產生 HTTP 通訊方式的平台與函式庫都可以使用，它也很常搭配 Open ID 使用，所以在一些大型網路服務平台 (ex: Google, Yahoo) 會看到 Open ID + OAuth 的格式，但 OAuth 本身也具備驗證能力，不過它是由服務端來做驗證。Open ID 亦不是本系列文的重點，所以我們只會在這系列文中看到 OAuth 的使用方式。

那 OAuth 是怎麼運作的呢？雖然各大網站都有提供 OAuth 的操作流程，但基本上會是以下圖的流程為準：

圖來自：http://oauth.net/core/1.0/

 

大體上會分為三個程序：

1. 用戶端應用程式向服務要求一個 Request Token，這個 Token 會用來識別應用程式要求存取的工作階段。
2. 用戶端應用程式開啟瀏覽器 (Desktop Application) 或由服務導向到授權的網頁 (Web Application)，由使用者決定是否授權，若使用者決定授權時，用戶端應用程式會得到一個 Verifier Token，這個 Token 會在稍後向服務要求存取權限。
3. 用戶端應用程式向服務提交 Request Token 與 Verifier Token，服務在驗證過後核發 Access Token，這個 Token 會在應用程式每次向服務要求資源時，由用戶端應用程式提交以驗證權限。

 

那麼服務是怎麼樣決定用戶端使用的是 OAuth 協定時，其實很簡單，是透過 HTTP Header 中的 Authorization 標頭資料，應用程式在 HTTP 要求中加入 OAuth oauth…. 的資訊，服務會拆解這個標頭中的 OAuth 資料進行檢查以驗證用戶端的權限，例如下面的 HTTP Request 就是典型的 OAuth 呼叫：

POST /accounts/OAuthGetRequestToken HTTP/1.1
Host: www.google.com
Content-Type: application/x-www-form-urlencoded
Authorization: OAuth
oauth_consumer_key="example.com",
oauth_signature_method="RSA-SHA1",
oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",
oauth_timestamp="137131200",
oauth_nonce="4572616e48616d6d65724c61686176",
oauth_version="1.0"
oauth_callback="http://www.example.com/showcalendar.html"

 

整個 OAuth 最困難的部份就是去搞懂這些在 OAuth 中規定的參數，而這也是使用 OAuth 協定開發用戶端應用程式的最大門檻，只要通過這個門檻後，之後的服務存取就變得十分簡單。

我們在下一回中，來說明這些參數的意義以及用法。