OAuth那些事兒

英國詩人蒲柏在牛頓的墓誌銘中寫道：『自然和自然的法則在黑暗中隱藏，上帝說，讓牛頓去吧，於是一切都被照亮！』，而在保護賬號安全方面，OAuth起著如同牛頓般中流砥柱的作用，為什麼這麼說呢？

人人網提供了匯入MSN聯絡人的功能，但前提是使用者必須提供賬號密碼，如下圖所示：

人人網信誓旦旦的宣稱不會記錄你的密碼，它甚至提供了一個所謂保證賬號安全的方法：先改密碼再匯入，成功後再改為原密碼。不過這樣做就安全了麼？

什麼是OAuth

如今很多網站的功能都強調彼此間的互動，因此我們需要一種簡單，標準的解決方案來安全的完成應用的授權，於是，OAuth應運而生，看看官網對其的定義：

An open protocol to allow secure API authorization  in a simple and standard method from desktop and web applications.

一個典型的OAuth應用通常包括三種角色，分別是：

• Consumer：消費方
• Service Provider：服務提供者
• User：使用者

使用者好理解，不必多言，消費方和服務提供者則需要解釋一下，舉例來說：假設我們做了一個SNS，它有一個功能，可以讓會員把他們在Google上的聯絡人匯入到SNS上，那麼此時的消費方就是SNS，而服務提供者則是Google。

消費方如果想使用服務提供者的OAuth功能，通常需要先申請兩樣東西：

• Consumer Key
• Consumer Secret

當消費方生成簽名的時候，會用到它們。

一個典型的OAuth流程通常如下圖所示：

• A：消費方請求Request Token
• B：服務提供者授權Request Token
• C：消費方定向使用者到服務提供者
• D：獲得使用者授權後，服務提供者定向使用者到消費方
• E：消費方請求Access Token
• F：服務提供者授權Access Token
• G：消費方訪問受保護的資源

基本就是用Request Token換取Access Token的過程。這裡需要注意的是，對服務提供者而言，Request Token和Access Token的生命週期不一樣，通常，Request Token的生命週期很短，一般在一個小時以內，這樣相對安全一些；而Access Token的生命週期很長，往往是無限，如此一來，消費方就可以把它儲存起來，以後的操作就無需使用者再授權了，即便使用者修改賬號密碼，也不會受影響，當然，使用者可以廢除消費方的授權。

有腿的OAuth

我們前面描述的OAuth，被稱為三條腿的OAuth（3-Legged OAuth），這也是OAuth的標準版本。這裡所謂的“三條腿”，指的是授權過程中涉及三步流程。不過有些情況下，不需要使用者的參與，此時就產生了一個變體，被稱作兩條腿的OAuth（2-Legged OAuth），兩條腿的OAuth和三條腿的OAuth相比，因為沒有使用者的參與，所以在流程中就不會涉及使用者授權的環節，而主要是通過Consumer Key和Consumer Secret來完成簽名的，此時的Consumer Key和Consumer
Secret基本等價於賬號和密碼的作用。

補充：關於腿的解釋詳見The OAuth Bible

OAuth簡史

2007年12月4日釋出了OAuth Core 1.0：

此版本的協議存在嚴重的安全漏洞：OAuth Security Advisory: 2009.1，更詳細的介紹可以參考：Explaining
the OAuth Session Fixation Attack。

2009年6月24日釋出了OAuth Core 1.0 Revision A：

此版本的協議修復了前一版本的安全漏洞，併成為RFC5849，我們現在使用的OAuth版本多半都是以此版本為基礎。

OAuth的未來：OAuth 2.0 Working Draft，…

OAuth和OpenID的區別

OAuth關注的是authorization；而OpenID側重的是authentication。從表面上看，這兩個英文單詞很容易混淆，但實際上，它們的含義有本質的區別：

• authorization: n. 授權，認可；批准，委任
• authentication: n. 證明；鑑定；證實

OAuth關注的是授權，即：“使用者能做什麼”；而OpenID關注的是證明，即：“使用者是誰”。

如果混淆了OAuth和OpenID的含義，後果很嚴重。以國內某網站開發的應用為例：它的功能是通過OAuth授權讓新浪微博和豆瓣的使用者使用各自的身份發表評論，如下圖所示：

錯誤的把OAuth當做OpenID使用

此類應用屬於身份證明問題，本應該通過OpenID來實現，但因為錯誤的使用了OAuth，從而帶來安全隱患：設想一下使用者只是在網站上發表了評論而已，但卻賦予了網站隨意操作自己私有資料的權利！這就好比：快遞員送包裹，為了證明收件人的身份，原本你只要給他看一下身份證即可，可你卻把防盜門鑰匙都給他了！Oh，My God！

收工！作為首尾呼應的結束語，請允許我套用蒲柏的話：『賬號和賬號的安全在黑暗中隱藏，上帝說：讓OAuth去吧，於是一切都被照亮！』，不過這可不是墓誌銘 。

補充：關於OAuth詳細的介紹可以參考Beginner’s Guide to OAuth。