OAuth2授权原理
最近在做第三方接入的，初步定下使用OAuth2協(xié)議，花了些時間對OAuth2的授權(quán)方式做了些了解。
我還記得一兩年前，跟一位同事聊起互聯(lián)網(wǎng)時，當時我說過一個想法：
目前不少較為稀有的資源，很多都是論壇提供下載的，論壇提供的下載往往要求一個論壇帳號，更有甚者，需回帖才可見，又或者下載需要消耗一定的虛擬貨幣，而這些貨幣可以用論壇活躍度而獲得。假設(shè)現(xiàn)在我是一個普通用戶，我要找某個資源。通過搜索引擎或者資料，我發(fā)現(xiàn)在某個論壇有這個資源下載，從其他地方獲得這個資源代價比較高或者說根本就找不著。當我準備下載時，很可能就被提示需登錄后才可下載，隨機被跳轉(zhuǎn)到注冊頁面。
為了這個資源注冊一個帳號？我想，無論誰在99%的情況下都不樂意去注冊一個只是用一次的帳號，偏偏有些論壇就是為了某些原因要求你必須提供一個帳號。好吧，像我這樣的人，當然是瞎填點信息注冊個帳號了事。至于注冊了帳號需不需要金幣或者多少聲望才能回帖下載之類的，這里就不嘮叨了。這個過程的關(guān)鍵點是：我為了一個臨時性的需要，注冊了一個永久性無關(guān)痛癢的帳號，這個帳號使用一次之后，基本上失去價值了。有無數(shù)無聊的用戶花了N多的時間在M多的論壇里注冊了N*M個無用帳號，這個過程除了對某些統(tǒng)計指標有利以外，對用戶沒有任何價值。
可不可以做一個平臺，使任意用戶可以在任意論壇注冊一個帳號，隨后這個帳號和密碼自動登記到這個平臺中作為公共帳號，之后，其他用戶再訪問這個論壇時，就無需再次注冊帳號了，直接在這個平臺上，自動地使用公共帳號去做該做的事。這樣，隨著用戶數(shù)的增加，最終可以達到一個比較理想的情況：大部分論壇的臨時性操作，用戶都不用再去注冊了，也不用擔心自己的常用帳號密碼等信息泄漏的問題。盡管對于一些有“經(jīng)濟系統(tǒng)”的論壇（需要通過活躍度/發(fā)帖數(shù)/現(xiàn)金等有償獲得虛擬貨幣，存在消費行為），這個平臺可能不適合，但即使需求只被解決了一半，也是個有價值的產(chǎn)品。
當時只是大概聊了下，完全沒有動手的打算，至今我還沒發(fā)現(xiàn)類似的產(chǎn)品，不知是這個需求不夠大眾還是什么。那時我也大概看了下OpenID，跟我的設(shè)想不一樣，OpenID是將一個用戶在某個平臺上的帳號，公開給其他網(wǎng)站使用，當然公開的只是帳號而不會包含密碼。當時宣傳的口號大概是這樣的：“一次登錄，到處使用”。當時我只在豌豆網(wǎng)注冊了一個OpenID試著玩玩，感覺支持這個OpenID的資源網(wǎng)站太少了，那個帳號作用不大。
OAuth最近幾年大行其道，很大程度得益于微博的推廣。OAuth和OpenID是比較容易混淆的兩個東西，比較“官方”的觀點認為：OpenID設(shè)計目的是“身份校驗”；OAuth的設(shè)計目的是“授權(quán)”。我也比較認同這個觀點，但我覺得這種說法本身也挺容易混淆，有位同事說“身份校驗”本身就是對“用戶資源”權(quán)限的授予，所以O(shè)Auth包含了OpenID的作用。
在說明我的觀點之前，不妨思考下，目前提供OAuth的網(wǎng)站有那些，他們的提供的服務(wù)是什么，為什么他們大多都提供OAuth卻鮮有提及OpenID?(我不是暗指騰訊啦)。
?
OAuth與OpenID
先看看OpenID，前面多少也講過了，下面以豌豆網(wǎng)為例：
服務(wù)提供方：豌豆網(wǎng)
提供的服務(wù)：用戶身份識別，同一個用戶有同一個OpenID描述，帳號密碼驗證功能由豌豆網(wǎng)提供
服務(wù)消費方：第三方
消費的目的：讓豌豆網(wǎng)的用戶來操作自己網(wǎng)站所擁有的資源
再來對比OAuth，用新浪微博為例吧：
服務(wù)提供方：新浪微博
提供的服務(wù)：讀取/發(fā)送/查詢微博，好友關(guān)系處理等，帳號密碼資源都由新浪微博提供
服務(wù)消費方：第三方
消費的目的：為終端用戶操作該用戶在新浪微博的資源提供可能
一對比，區(qū)別就很明顯了：OAuth和OpenID的區(qū)別主要是服務(wù)提供方是否提供有價值的資源。
作為一個擁有資源的服務(wù)提供方，當然希望自己管理自己的用戶信息。假如新浪微博支持其他網(wǎng)站的OpenID登錄，由于有不少的OpenID服務(wù)提供方，那么它需要如何管理自己的用戶呢？例如，用戶A通過網(wǎng)站X的OpenID登錄新浪微博，跟用戶A通過網(wǎng)站Y的OpenID登錄新浪微博，最終的效果是一個帳號還是兩個帳號呢？如果用戶A在新浪微博本身有一個帳號的話，情況又更復雜了。要么所有帳號都按新帳號處理，要么提供多個帳號關(guān)聯(lián)功能。前一種方案簡單易行，但產(chǎn)生了大量非活躍帳號，用戶體驗也不見得好。后一種方案，想一想都覺得，維護是個災(zāi)難。于是，大多數(shù)的資源提供方都傾向與自己管理自己的用戶信息，對于第三方的接入，開放一些授權(quán)給他們參與一些用戶資源的訪問就是了，于是便提供OAuth服務(wù)而不是提供OpenID接入，一些網(wǎng)站如騰訊還在 OAuth上提供了OpenID。寫著寫著，我自己都覺得OpenID的“接入”和"服務(wù)"很拗口。好吧，OpenID的接入是說使用其他網(wǎng)站所驗證的帳號信息，OpenID的服務(wù)是指對外提供OpenID的身份校驗服務(wù)。
把上面的情況循環(huán)循環(huán)再循環(huán)，最終，一方面，擁有有價值資源的網(wǎng)站，都做OAuth去了，他們在等待開發(fā)者和其他第三方網(wǎng)站的接入，壯大他們的平臺；另一方面，提供OpenID服務(wù)的小網(wǎng)站，幾乎沒有大網(wǎng)站的接入支持，對用戶的吸引力越來越小，典型的惡性循環(huán)。然后，大部分網(wǎng)站的OAuth服務(wù)雖然基本是按照官網(wǎng)規(guī)范做接口，但不少細節(jié)都做了個性化。例如部分網(wǎng)站的expires_in單位是秒，部分是用分做單位的。部分網(wǎng)站支持state作為狀態(tài)傳遞，部分又不支持。最終這些非標準的東西，會惹惱苦逼的開發(fā)者（為什么我會很自然的想起IE?），相信很多開發(fā)者都會根據(jù)市場份額去選擇幾個流行的OAuth提供方進行兼容，其他的，見喬布斯去吧。而用戶則會根據(jù)應(yīng)用的數(shù)量去選擇平臺，又一個惡性循環(huán)。如果你的資源不夠吸引開發(fā)者，就不會有人愿意為你的自定義標準買單。莫非這就是傳說中的，合久必分分久必合？嗯，扯遠了。
我并沒有貶OpenID褒OAuth的意思，只是覺得在目前市場下，不太可能有大網(wǎng)站愿意放棄提供OAuth服務(wù)而使用OpenID接入外部帳號。其實我對OpenID了解不多，寫著寫著，沒想到竟然寫了一大坨，我真懷疑自己是不是話癆…… 有點晚，明晚繼續(xù)，if有空的話。
OAuth授權(quán)流程
OAuth2是從OAuth發(fā)展而來的，雖然不向下兼容，但了解OAuth能更好的理解OAuth2的一些改變。
OAuth里存在三個主要角色：用戶、服務(wù)提供方和服務(wù)消費方。不少文檔會把服務(wù)消費方說成是客戶端，對于SP來說，這個說法沒什么問題，但我感覺這個說放容易引起混淆，所以我這里還是用服務(wù)消費方來描述。按流行的口號，服務(wù)提供方一般對外宣稱自己是某某某開放平臺，而服務(wù)消費方則是各種第三方應(yīng)用。用戶在平臺上有一些已有資源，如好友關(guān)系，照片等。
幾乎所有的OAuth平臺都有類似的背景：他們原先積累了一大堆的真實用戶，在互聯(lián)網(wǎng)開放的趨勢下，主動或被動的需要支持第三方應(yīng)用的接入。第三方應(yīng)用為了使其功能更加豐富完整，希望從平臺能獲取甚至操作當前用戶的資源。用戶很可能不希望第三方得知他原有的帳號和密碼，原因很明顯，安全考慮嘛。服務(wù)提供方也不希望第三方直接使用用戶的帳號和密碼登錄平臺操作用戶數(shù)據(jù)，為啥？不便于數(shù)據(jù)統(tǒng)計和維護嘛，希望對 哪個第三方操作哪個用戶數(shù)據(jù) 和 哪個用戶操作自己的數(shù)據(jù) 兩種處理流程有所區(qū)別。第三方很無辜，經(jīng)常大喊“我覺不會使用任何途徑存儲用戶的帳號！”。即使真有人相信這些誓言，但也很難確保第三方使用帳號敏感數(shù)據(jù)時，不被第四方所捕獲，所以，認真你就輸了。
為了解決上面的問題，準確的說是讓三種角色互相信任，OAuth由此而生。在沒有第三方的情況下，服務(wù)提供方和用戶可以認為是互相信任的，因為用戶用域名來確保自己訪問的是一個受信的站點；服務(wù)提供方則要求用戶登錄，并且登錄會話可以控制。
應(yīng)為第三方一般是不知名的，用戶很難區(qū)分第三方合不合法，所以用戶需要通過服務(wù)提供方來證實第三方，例如位于服務(wù)提供方的OAuth授權(quán)頁面會簡單的介紹該應(yīng)用的簡單介紹，正是這些介紹使得用戶可以相信，該應(yīng)用是一個合法登記的第三方。
為了讓服務(wù)提供方信任第三方應(yīng)用，第三方應(yīng)用在必要時需要向服務(wù)提供方提供身份憑據(jù)。最簡單的辦法就是第三方開發(fā)者去服務(wù)提供方那去注冊個帳號，然后在需要時用這個帳號來證明自己的身份。這種第三方應(yīng)用的帳號，下面統(tǒng)稱應(yīng)用帳號。由于第三方的請求不會有人工的干預，所以應(yīng)用帳號的帳號密碼一般由服務(wù)提供商提供，方便服務(wù)提供方管理，安全系數(shù)也較高，因為服務(wù)提供方可以制定規(guī)則，使密碼更難以偽造或猜測。
按理說，第三方應(yīng)用除了到SP處申請一個應(yīng)用帳號外，也有其他辦法證實自己的身份。
例如可以使用HTTPS連接，讓“第四方”去證明。OAuth2使用的就是HTTPS連接，但也僅僅是服務(wù)端認證，客戶端并不做保證。估計一個方面的原因是，應(yīng)用的數(shù)量很多，一般都是中小規(guī)模開發(fā)商開發(fā)的，客戶端也要認證的話，證書申請門檻較高，一個賬號密碼可以解決的問題有必要去申請證書嗎？另一方面是，很多應(yīng)用是沒有服務(wù)端的，使用雙向HTTPS認證無疑將這些應(yīng)用拒之門外。
上面的方法是，用戶通過服務(wù)提供方，去識別第三方是否合法。還有種方式是：服務(wù)提供方通過用戶，去識別第三方是否合法。但OAuth里沒有這種方式的體現(xiàn)，但OAuth2里有類似的方式，那就是提供用戶的帳號密碼換取AccessToken，名字應(yīng)該叫“資源所有者密碼憑據(jù)”。如果第三方應(yīng)用只是開發(fā)者自娛自樂的小應(yīng)用，這種方式是最簡單的。
經(jīng)過上面的注冊和授權(quán)流程，用戶和服務(wù)提供方都可以確認第三方應(yīng)用的身份了，那第三方如何確認服務(wù)提供方和用戶的身份？
第三方應(yīng)用怎么確認服務(wù)提供方的身份呢？很簡單，域名就是服務(wù)提供方的唯一標識，只要DNS不被劫持的話。第三方應(yīng)用根據(jù)服務(wù)提供方的返回內(nèi)容確認用戶身份，載體是操作令牌AccessToken，為了方便后面統(tǒng)稱ATOK，在OAuth里，ATOK的有效期是從用戶授權(quán)成功，到用戶取消授權(quán)，對第三方來說，幾乎是永久的。至于用戶授權(quán)之后取消授權(quán)，再授權(quán)的時候，兩次ATOK是否一樣，第三方能否處理好這種情況，OAuth里沒有提及，看實現(xiàn)者的心情了。
? 把上面所說的綜合在一起，可以得到一個OAuth的雛形版本：
第三方到服務(wù)提供方注冊個應(yīng)用帳號，當需要操作用戶在服務(wù)提供方處的數(shù)據(jù)時，提供應(yīng)用帳號密碼申請授權(quán)，服務(wù)提供方將用戶引導到授權(quán)頁面，當授權(quán)成功時，服務(wù)提供方將對應(yīng)該用戶的ATOK發(fā)給應(yīng)用，隨后應(yīng)用就使用這個ATOK來操作用戶數(shù)據(jù)。
下面新浪微博OAuth的基本流程（其實各平臺的流程都一樣，貼這個是覺得這張圖比較好看）：
從圖中可以看到OAuth的流程比原先設(shè)想的雛形多了不少東西，這些多出來的有什么作用呢？
四個步驟
OAuth授權(quán)分四步。
第一步，應(yīng)用向服務(wù)提供方申請請求令牌(Request Token)，服務(wù)提供方驗證通過后將令牌返回。這個步驟由于涉及到應(yīng)用帳號密碼，在應(yīng)用的服務(wù)端發(fā)起，所以這個步驟對用戶透明。
第二步，應(yīng)用使用請求令牌讓瀏覽器重定向到服務(wù)提供方進行登錄驗證和授權(quán)。服務(wù)提供方校驗請求令牌，將第三方的資料顯示給用戶，提示用戶選擇同意或拒絕此次授權(quán)。如果用戶同意授權(quán)，發(fā)放已授權(quán)令牌并將用戶引導到當前應(yīng)用的注冊地址。這個步驟從重定向開始到引導回注冊地址之前，應(yīng)用方并不參與用戶身份校驗和授權(quán)過程，確保第三方不可獲得用戶的真實帳號密碼。
第三步，用已授權(quán)令牌向服務(wù)提供方換取ATOK。第三方應(yīng)用需在服務(wù)端發(fā)起請求，用帳號密碼和上一步的令牌換取ATOK，這個步驟對用戶而言也是透明的。如果前兩步分別是讓服務(wù)提供方認證應(yīng)用和用戶，那這步就是用戶和服務(wù)提供方再次認證第三方應(yīng)用。因為用戶瀏覽器將第二步的結(jié)果重定向到第三步，除非用戶DNS被劫持，否則就能確保重定向到的是合法的地址。曾經(jīng)我很困惑在用戶授權(quán)之后為何不直接返回ATOK而需要再次換取，估計是出于對ATOK的安全考慮，用戶瀏覽器一端存在太多的可能性讓ATOK泄漏，最安全的辦法還是讓第三方服務(wù)端來獲取和保管ATOK。
第四步，用ATOK作為令牌訪問受保護資源。很多時候，權(quán)限是有多種類別的。ATOK包含了某個用戶對某個應(yīng)用的授權(quán)憑據(jù)，準確的說，ATOK對應(yīng)用戶授權(quán)時所賦予的一系列權(quán)限的集合。所以在這一步，除了校驗ATOK的合法性之外，服務(wù)提供方還需對該ATOK是否擁有足夠的權(quán)限執(zhí)行被保護操作進行判斷。
單次簽名
在OAuth里，OAuth的相關(guān)請求都要做單次簽名，目的是防止OAuth的請求被篡改和重放。簽名當然是拿應(yīng)用帳號的密碼來做簽名，其實就是對HTTP請求中所有OAuth相關(guān)的參數(shù)都連在一塊，使用密碼計算某種哈希值作為簽名。OAuth規(guī)范里描述了簽名的規(guī)則，那是相當?shù)姆爆崱碗s，足以嚇跑一大堆未經(jīng)世事的開發(fā)者。隨便找一個OAuth開放平臺的API文檔，我相信在OAuth授權(quán)流程有接近一半會在描述怎么產(chǎn)生簽名構(gòu)造一個合法的HTTP請求。有一對文字圖片描述還不夠，各開放平臺幾乎無一例外地提供各種開發(fā)語言下的SDK，為求盡量降低技術(shù)門檻。即使如此，不少開發(fā)者依然覺得，OAuth的簽名過程實在是太復雜了，而這些復雜也沒有帶來預期的好處。
重定向地址
為了防止有攻擊者偽造重定向地址騙取用戶授權(quán)，服務(wù)提供方應(yīng)對授權(quán)時的重定向地址進行驗證。所以注冊時，第三方應(yīng)提供重定向地址。服務(wù)提供方可以直接對重定向地址進行等值判斷，但這樣的話就沒辦法讓第三方在授權(quán)過程中傳遞狀態(tài)，只能借助Cookie/Session之類的方式了。服務(wù)提供方也可以判斷重定向地址是否同一個域，這樣的話應(yīng)用方就可以在URI里傳遞少量狀態(tài)。對于一些沒有服務(wù)端的第三方Web應(yīng)用，由于代碼是公開的，將應(yīng)用的帳號密碼存在頁面里并不合適。OAuth則建議不使用重定向地址，讓用戶在授權(quán)后，把授權(quán)碼人工輸入到應(yīng)用中進行下一步。記得有段時間FaWave也是這么添加新帳號的。
安全漏洞
OAuth曾爆了一個安全漏洞，攻擊者利用此漏洞可騙取用戶信任獲取非法的授權(quán)。
這個網(wǎng)頁有該漏洞的詳細說明，流程如下：
簡單的說，這個漏洞主要的關(guān)鍵是：
1. 部分服務(wù)提供方并未對重定向地址進行合法性判斷，或者部分第三方的重定向地址會根據(jù)URI的參數(shù)再次重定向從而被攻擊者利用；
2.?RequestToken從未授權(quán)到已授權(quán)的狀態(tài)轉(zhuǎn)變時沒有變化，從而為攻擊者暴力訪問回調(diào)地址騙取ATOK提供可能；
對于第一點，攻擊者偽造重定向地址，即可騙得用戶對可靠第三方的授權(quán)，獲得ATOK
對于第二點，假如第一點不成立，那攻擊者可以用第一步的請求令牌構(gòu)造一個合法的重定向請求，并在用戶授權(quán)之后、瀏覽器重定向到合法重定向地址之前，進行同樣操作執(zhí)行這個重定向操作，此時就看攻擊者和正常授權(quán)流程就存在競爭關(guān)系。如果第三方先處理攻擊者的請求，攻擊者就獲得了最終的ATOK。
為了解決上述安全漏洞，OAuth更新了1.0a版本，主要改變就是第一步增加對重定向地址的簽名，和第二步與第三步之間增加一個隨機校驗碼，使之與未授權(quán)的RequestToken有所區(qū)分。
? 目前大部分的平臺都轉(zhuǎn)到了OAuth2。OAuth2雖并不兼容OAuth1，但基本原理是一樣的。
?
OAuth2的改變
OAuth2對比OAuth1，主要改變有下面幾點：
1. 取消繁瑣的簽名，全部改用HTTPS。
2. ATOK從原來的永久令牌變?yōu)榕R時令牌，增加RefreshToken
3. 取消獲取RequestToken的步驟
4. 提供了多種場景的授權(quán)流程
HTTPS
OAuth原有的簽名算法實在是太繁瑣了，嚇跑了不少開發(fā)者。對于服務(wù)提供方，也很不好實現(xiàn)，特別是單次簽名的實現(xiàn)，由于服務(wù)提供方要確保每次由客戶端生成的隨機碼不被重復利用，必須存儲每次請求發(fā)來的隨機碼，無論是對存儲還是校驗都是一個難題。通常的做法是，存儲一段時間的隨機碼，這個時間需比RequestToken的過期時間要長。這樣即使到時還有重放攻擊，RequestToken也已經(jīng)失效。
OAuth2取消了簽名，改用HTTPS來加密，確保通信內(nèi)容不被第三方竊取。這個改變毫無疑問是降低了門檻，授權(quán)的流程被簡化了。雖有少量人有異議，但OAuth2最大的異議是臨時的ATOK。
ATOK與RefreshToken
由于第三方應(yīng)用往往不重視ATOK的安全性，開發(fā)者為圖方便經(jīng)常把ATOK從后端發(fā)給前端頁面或者存在cookie中。由于OAuth1中ATOK幾乎是永久性的，即使發(fā)現(xiàn)ATOK被盜用，也只能讓用戶取消授權(quán)，這可能會造成一些其他的問題。OAuth2將ATOK改為臨時令牌，當ATOK過期后，需要使用RefreshToken重新獲取新的ATOK，讓開發(fā)者郁悶的是，RefreshToken也不是永久性的，不同的服務(wù)提供方有不同的過期時間，相同的是，過期時間都不會太長，頂多也就幾個月。
這個改變對很多第三方應(yīng)用是個坑爹的改變，原本他們幾乎都是拿ATOK作為OpenID來使用的（所以才有了各種ATOK被盜用的隱患），而到了OAuth2，ATOK已經(jīng)不能唯一標識一個用戶了，他們要多做很多的東西才能維持用戶的身份，在使用ATOK訪問用戶資源時，步驟也是異常繁瑣。
雖然臨時ATOK這個改變很合理，但對開發(fā)者很不友好，今后會不會繼續(xù)改變，可以拭目以待。我個人覺得，這個問題其實是另外一個問題，那就是開發(fā)者對用戶帳號信息的安全意識太單薄，后面講OAuth的問題時再詳細討論。
授權(quán)流程
OAuth1流程比較復雜，盡管規(guī)范里有對多種場景的授權(quán)流程進行不同的建議，但很多應(yīng)用和開放平臺最終都使用了同一種授權(quán)流程，結(jié)果產(chǎn)生了安全隱患（例如上面重定向地址的問題嗎）。OAuth2描述了四種授權(quán)場景，為這些場景下的授權(quán)流程提供指導。我只簡單說些要點和差異，詳細的說明還是看官方文檔和各開放平臺的文檔穩(wěn)妥些。
(待續(xù))
轉(zhuǎn)載于:https://www.cnblogs.com/neutra/archive/2012/07/26/2609300.html
總結(jié)
以上是生活随笔為你收集整理的OAuth2授权原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 新年新气象——开篇
- 下一篇： 发微博利器 FaWave（发微）----