最近在做第三方接入的，初步定下使用OAuth2協(xié)議，花了些時(shí)間對(duì)OAuth2的授權(quán)方式做了些了解。

　　我還記得一兩年前，跟一位同事聊起互聯(lián)網(wǎng)時(shí)，當(dāng)時(shí)我說(shuō)過一個(gè)想法：

　　目前不少較為稀有的資源，很多都是論壇提供下載的，論壇提供的下載往往要求一個(gè)論壇帳號(hào)，更有甚者，需回帖才可見，又或者下載需要消耗一定的虛擬貨幣，而這些貨幣可以用論壇活躍度而獲得。假設(shè)現(xiàn)在我是一個(gè)普通用戶，我要找某個(gè)資源。通過搜索引擎或者資料，我發(fā)現(xiàn)在某個(gè)論壇有這個(gè)資源下載，從其他地方獲得這個(gè)資源代價(jià)比較高或者說(shuō)根本就找不著。當(dāng)我準(zhǔn)備下載時(shí)，很可能就被提示需登錄后才可下載，隨機(jī)被跳轉(zhuǎn)到注冊(cè)頁(yè)面。

　　為了這個(gè)資源注冊(cè)一個(gè)帳號(hào)？我想，無(wú)論誰(shuí)在99%的情況下都不樂意去注冊(cè)一個(gè)只是用一次的帳號(hào)，偏偏有些論壇就是為了某些原因要求你必須提供一個(gè)帳號(hào)。好吧，像我這樣的人，當(dāng)然是瞎填點(diǎn)信息注冊(cè)個(gè)帳號(hào)了事。至于注冊(cè)了帳號(hào)需不需要金幣或者多少聲望才能回帖下載之類的，這里就不嘮叨了。這個(gè)過程的關(guān)鍵點(diǎn)是：我為了一個(gè)臨時(shí)性的需要，注冊(cè)了一個(gè)永久性無(wú)關(guān)痛癢的帳號(hào)，這個(gè)帳號(hào)使用一次之后，基本上失去價(jià)值了。有無(wú)數(shù)無(wú)聊的用戶花了N多的時(shí)間在M多的論壇里注冊(cè)了N*M個(gè)無(wú)用帳號(hào)，這個(gè)過程除了對(duì)某些統(tǒng)計(jì)指標(biāo)有利以外，對(duì)用戶沒有任何價(jià)值。

　　可不可以做一個(gè)平臺(tái)，使任意用戶可以在任意論壇注冊(cè)一個(gè)帳號(hào)，隨后這個(gè)帳號(hào)和密碼自動(dòng)登記到這個(gè)平臺(tái)中作為公共帳號(hào)，之后，其他用戶再訪問這個(gè)論壇時(shí)，就無(wú)需再次注冊(cè)帳號(hào)了，直接在這個(gè)平臺(tái)上，自動(dòng)地使用公共帳號(hào)去做該做的事。這樣，隨著用戶數(shù)的增加，最終可以達(dá)到一個(gè)比較理想的情況：大部分論壇的臨時(shí)性操作，用戶都不用再去注冊(cè)了，也不用擔(dān)心自己的常用帳號(hào)密碼等信息泄漏的問題。盡管對(duì)于一些有“經(jīng)濟(jì)系統(tǒng)”的論壇（需要通過活躍度/發(fā)帖數(shù)/現(xiàn)金等有償獲得虛擬貨幣，存在消費(fèi)行為），這個(gè)平臺(tái)可能不適合，但即使需求只被解決了一半，也是個(gè)有價(jià)值的產(chǎn)品。

　　當(dāng)時(shí)只是大概聊了下，完全沒有動(dòng)手的打算，至今我還沒發(fā)現(xiàn)類似的產(chǎn)品，不知是這個(gè)需求不夠大眾還是什么。那時(shí)我也大概看了下OpenID，跟我的設(shè)想不一樣，OpenID是將一個(gè)用戶在某個(gè)平臺(tái)上的帳號(hào)，公開給其他網(wǎng)站使用，當(dāng)然公開的只是帳號(hào)而不會(huì)包含密碼。當(dāng)時(shí)宣傳的口號(hào)大概是這樣的：“一次登錄，到處使用”。當(dāng)時(shí)我只在豌豆網(wǎng)注冊(cè)了一個(gè)OpenID試著玩玩，感覺支持這個(gè)OpenID的資源網(wǎng)站太少了，那個(gè)帳號(hào)作用不大。

　　OAuth最近幾年大行其道，很大程度得益于微博的推廣。OAuth和OpenID是比較容易混淆的兩個(gè)東西，比較“官方”的觀點(diǎn)認(rèn)為：OpenID設(shè)計(jì)目的是“身份校驗(yàn)”；OAuth的設(shè)計(jì)目的是“授權(quán)”。我也比較認(rèn)同這個(gè)觀點(diǎn)，但我覺得這種說(shuō)法本身也挺容易混淆，有位同事說(shuō)“身份校驗(yàn)”本身就是對(duì)“用戶資源”權(quán)限的授予，所以O(shè)Auth包含了OpenID的作用。

　　在說(shuō)明我的觀點(diǎn)之前，不妨思考下，目前提供OAuth的網(wǎng)站有那些，他們的提供的服務(wù)是什么，為什么他們大多都提供OAuth卻鮮有提及OpenID?(我不是暗指騰訊啦)。

?

OAuth與OpenID

　　先看看OpenID，前面多少也講過了，下面以豌豆網(wǎng)為例：
　　　　服務(wù)提供方：豌豆網(wǎng)
　　　　提供的服務(wù)：用戶身份識(shí)別，同一個(gè)用戶有同一個(gè)OpenID描述，帳號(hào)密碼驗(yàn)證功能由豌豆網(wǎng)提供
　　　　服務(wù)消費(fèi)方：第三方
　　　　消費(fèi)的目的：讓豌豆網(wǎng)的用戶來(lái)操作自己網(wǎng)站所擁有的資源
　　再來(lái)對(duì)比OAuth，用新浪微博為例吧：
　　　　服務(wù)提供方：新浪微博
　　　　提供的服務(wù)：讀取/發(fā)送/查詢微博，好友關(guān)系處理等，帳號(hào)密碼資源都由新浪微博提供
　　　　服務(wù)消費(fèi)方：第三方
　　　　消費(fèi)的目的：為終端用戶操作該用戶在新浪微博的資源提供可能
　　一對(duì)比，區(qū)別就很明顯了：OAuth和OpenID的區(qū)別主要是服務(wù)提供方是否提供有價(jià)值的資源。
作為一個(gè)擁有資源的服務(wù)提供方，當(dāng)然希望自己管理自己的用戶信息。假如新浪微博支持其他網(wǎng)站的OpenID登錄，由于有不少的OpenID服務(wù)提供方，那么它需要如何管理自己的用戶呢？例如，用戶A通過網(wǎng)站X的OpenID登錄新浪微博，跟用戶A通過網(wǎng)站Y的OpenID登錄新浪微博，最終的效果是一個(gè)帳號(hào)還是兩個(gè)帳號(hào)呢？如果用戶A在新浪微博本身有一個(gè)帳號(hào)的話，情況又更復(fù)雜了。要么所有帳號(hào)都按新帳號(hào)處理，要么提供多個(gè)帳號(hào)關(guān)聯(lián)功能。前一種方案簡(jiǎn)單易行，但產(chǎn)生了大量非活躍帳號(hào)，用戶體驗(yàn)也不見得好。后一種方案，想一想都覺得，維護(hù)是個(gè)災(zāi)難。于是，大多數(shù)的資源提供方都傾向與自己管理自己的用戶信息，對(duì)于第三方的接入，開放一些授權(quán)給他們參與一些用戶資源的訪問就是了，于是便提供OAuth服務(wù)而不是提供OpenID接入，一些網(wǎng)站如騰訊還在 OAuth上提供了OpenID。寫著寫著，我自己都覺得OpenID的“接入”和"服務(wù)"很拗口。好吧，OpenID的接入是說(shuō)使用其他網(wǎng)站所驗(yàn)證的帳號(hào)信息，OpenID的服務(wù)是指對(duì)外提供OpenID的身份校驗(yàn)服務(wù)。
　　把上面的情況循環(huán)循環(huán)再循環(huán)，最終，一方面，擁有有價(jià)值資源的網(wǎng)站，都做OAuth去了，他們?cè)诘却_發(fā)者和其他第三方網(wǎng)站的接入，壯大他們的平臺(tái)；另一方面，提供OpenID服務(wù)的小網(wǎng)站，幾乎沒有大網(wǎng)站的接入支持，對(duì)用戶的吸引力越來(lái)越小，典型的惡性循環(huán)。然后，大部分網(wǎng)站的OAuth服務(wù)雖然基本是按照官網(wǎng)規(guī)范做接口，但不少細(xì)節(jié)都做了個(gè)性化。例如部分網(wǎng)站的expires_in單位是秒，部分是用分做單位的。部分網(wǎng)站支持state作為狀態(tài)傳遞，部分又不支持。最終這些非標(biāo)準(zhǔn)的東西，會(huì)惹惱苦逼的開發(fā)者（為什么我會(huì)很自然的想起IE?），相信很多開發(fā)者都會(huì)根據(jù)市場(chǎng)份額去選擇幾個(gè)流行的OAuth提供方進(jìn)行兼容，其他的，見喬布斯去吧。而用戶則會(huì)根據(jù)應(yīng)用的數(shù)量去選擇平臺(tái)，又一個(gè)惡性循環(huán)。如果你的資源不夠吸引開發(fā)者，就不會(huì)有人愿意為你的自定義標(biāo)準(zhǔn)買單。莫非這就是傳說(shuō)中的，合久必分分久必合？嗯，扯遠(yuǎn)了。
　　我并沒有貶OpenID褒OAuth的意思，只是覺得在目前市場(chǎng)下，不太可能有大網(wǎng)站愿意放棄提供OAuth服務(wù)而使用OpenID接入外部帳號(hào)。其實(shí)我對(duì)OpenID了解不多，寫著寫著，沒想到竟然寫了一大坨，我真懷疑自己是不是話癆…… 有點(diǎn)晚，明晚繼續(xù)，if有空的話。

OAuth授權(quán)流程

　　OAuth2是從OAuth發(fā)展而來(lái)的，雖然不向下兼容，但了解OAuth能更好的理解OAuth2的一些改變。
OAuth里存在三個(gè)主要角色：用戶、服務(wù)提供方和服務(wù)消費(fèi)方。不少文檔會(huì)把服務(wù)消費(fèi)方說(shuō)成是客戶端，對(duì)于SP來(lái)說(shuō)，這個(gè)說(shuō)法沒什么問題，但我感覺這個(gè)說(shuō)放容易引起混淆，所以我這里還是用服務(wù)消費(fèi)方來(lái)描述。按流行的口號(hào)，服務(wù)提供方一般對(duì)外宣稱自己是某某某開放平臺(tái)，而服務(wù)消費(fèi)方則是各種第三方應(yīng)用。用戶在平臺(tái)上有一些已有資源，如好友關(guān)系，照片等。

　　幾乎所有的OAuth平臺(tái)都有類似的背景：他們?cè)确e累了一大堆的真實(shí)用戶，在互聯(lián)網(wǎng)開放的趨勢(shì)下，主動(dòng)或被動(dòng)的需要支持第三方應(yīng)用的接入。第三方應(yīng)用為了使其功能更加豐富完整，希望從平臺(tái)能獲取甚至操作當(dāng)前用戶的資源。用戶很可能不希望第三方得知他原有的帳號(hào)和密碼，原因很明顯，安全考慮嘛。服務(wù)提供方也不希望第三方直接使用用戶的帳號(hào)和密碼登錄平臺(tái)操作用戶數(shù)據(jù)，為啥？不便于數(shù)據(jù)統(tǒng)計(jì)和維護(hù)嘛，希望對(duì) 哪個(gè)第三方操作哪個(gè)用戶數(shù)據(jù) 和 哪個(gè)用戶操作自己的數(shù)據(jù) 兩種處理流程有所區(qū)別。第三方很無(wú)辜，經(jīng)常大喊“我覺不會(huì)使用任何途徑存儲(chǔ)用戶的帳號(hào)！”。即使真有人相信這些誓言，但也很難確保第三方使用帳號(hào)敏感數(shù)據(jù)時(shí)，不被第四方所捕獲，所以，認(rèn)真你就輸了。

　　為了解決上面的問題，準(zhǔn)確的說(shuō)是讓三種角色互相信任，OAuth由此而生。在沒有第三方的情況下，服務(wù)提供方和用戶可以認(rèn)為是互相信任的，因?yàn)橛脩粲糜蛎麃?lái)確保自己訪問的是一個(gè)受信的站點(diǎn)；服務(wù)提供方則要求用戶登錄，并且登錄會(huì)話可以控制。

　　應(yīng)為第三方一般是不知名的，用戶很難區(qū)分第三方合不合法，所以用戶需要通過服務(wù)提供方來(lái)證實(shí)第三方，例如位于服務(wù)提供方的OAuth授權(quán)頁(yè)面會(huì)簡(jiǎn)單的介紹該應(yīng)用的簡(jiǎn)單介紹，正是這些介紹使得用戶可以相信，該應(yīng)用是一個(gè)合法登記的第三方。

　　為了讓服務(wù)提供方信任第三方應(yīng)用，第三方應(yīng)用在必要時(shí)需要向服務(wù)提供方提供身份憑據(jù)。最簡(jiǎn)單的辦法就是第三方開發(fā)者去服務(wù)提供方那去注冊(cè)個(gè)帳號(hào)，然后在需要時(shí)用這個(gè)帳號(hào)來(lái)證明自己的身份。這種第三方應(yīng)用的帳號(hào)，下面統(tǒng)稱應(yīng)用帳號(hào)。由于第三方的請(qǐng)求不會(huì)有人工的干預(yù)，所以應(yīng)用帳號(hào)的帳號(hào)密碼一般由服務(wù)提供商提供，方便服務(wù)提供方管理，安全系數(shù)也較高，因?yàn)榉?wù)提供方可以制定規(guī)則，使密碼更難以偽造或猜測(cè)。

　　按理說(shuō)，第三方應(yīng)用除了到SP處申請(qǐng)一個(gè)應(yīng)用帳號(hào)外，也有其他辦法證實(shí)自己的身份。

　　例如可以使用HTTPS連接，讓“第四方”去證明。OAuth2使用的就是HTTPS連接，但也僅僅是服務(wù)端認(rèn)證，客戶端并不做保證。估計(jì)一個(gè)方面的原因是，應(yīng)用的數(shù)量很多，一般都是中小規(guī)模開發(fā)商開發(fā)的，客戶端也要認(rèn)證的話，證書申請(qǐng)門檻較高，一個(gè)賬號(hào)密碼可以解決的問題有必要去申請(qǐng)證書嗎？另一方面是，很多應(yīng)用是沒有服務(wù)端的，使用雙向HTTPS認(rèn)證無(wú)疑將這些應(yīng)用拒之門外。

　　上面的方法是，用戶通過服務(wù)提供方，去識(shí)別第三方是否合法。還有種方式是：服務(wù)提供方通過用戶，去識(shí)別第三方是否合法。但OAuth里沒有這種方式的體現(xiàn)，但OAuth2里有類似的方式，那就是提供用戶的帳號(hào)密碼換取AccessToken，名字應(yīng)該叫“資源所有者密碼憑據(jù)”。如果第三方應(yīng)用只是開發(fā)者自?shī)首詷返男?yīng)用，這種方式是最簡(jiǎn)單的。

　　經(jīng)過上面的注冊(cè)和授權(quán)流程，用戶和服務(wù)提供方都可以確認(rèn)第三方應(yīng)用的身份了，那第三方如何確認(rèn)服務(wù)提供方和用戶的身份？

　　第三方應(yīng)用怎么確認(rèn)服務(wù)提供方的身份呢？很簡(jiǎn)單，域名就是服務(wù)提供方的唯一標(biāo)識(shí)，只要DNS不被劫持的話。第三方應(yīng)用根據(jù)服務(wù)提供方的返回內(nèi)容確認(rèn)用戶身份，載體是操作令牌AccessToken，為了方便后面統(tǒng)稱ATOK，在OAuth里，ATOK的有效期是從用戶授權(quán)成功，到用戶取消授權(quán)，對(duì)第三方來(lái)說(shuō)，幾乎是永久的。至于用戶授權(quán)之后取消授權(quán)，再授權(quán)的時(shí)候，兩次ATOK是否一樣，第三方能否處理好這種情況，OAuth里沒有提及，看實(shí)現(xiàn)者的心情了。

?　　把上面所說(shuō)的綜合在一起，可以得到一個(gè)OAuth的雛形版本：

　　第三方到服務(wù)提供方注冊(cè)個(gè)應(yīng)用帳號(hào)，當(dāng)需要操作用戶在服務(wù)提供方處的數(shù)據(jù)時(shí)，提供應(yīng)用帳號(hào)密碼申請(qǐng)授權(quán)，服務(wù)提供方將用戶引導(dǎo)到授權(quán)頁(yè)面，當(dāng)授權(quán)成功時(shí)，服務(wù)提供方將對(duì)應(yīng)該用戶的ATOK發(fā)給應(yīng)用，隨后應(yīng)用就使用這個(gè)ATOK來(lái)操作用戶數(shù)據(jù)。

　　下面新浪微博OAuth的基本流程（其實(shí)各平臺(tái)的流程都一樣，貼這個(gè)是覺得這張圖比較好看）：

　　從圖中可以看到OAuth的流程比原先設(shè)想的雛形多了不少東西，這些多出來(lái)的有什么作用呢？

　　四個(gè)步驟

　　OAuth授權(quán)分四步。

　　第一步，應(yīng)用向服務(wù)提供方申請(qǐng)請(qǐng)求令牌(Request Token)，服務(wù)提供方驗(yàn)證通過后將令牌返回。這個(gè)步驟由于涉及到應(yīng)用帳號(hào)密碼，在應(yīng)用的服務(wù)端發(fā)起，所以這個(gè)步驟對(duì)用戶透明。

　　第二步，應(yīng)用使用請(qǐng)求令牌讓瀏覽器重定向到服務(wù)提供方進(jìn)行登錄驗(yàn)證和授權(quán)。服務(wù)提供方校驗(yàn)請(qǐng)求令牌，將第三方的資料顯示給用戶，提示用戶選擇同意或拒絕此次授權(quán)。如果用戶同意授權(quán)，發(fā)放已授權(quán)令牌并將用戶引導(dǎo)到當(dāng)前應(yīng)用的注冊(cè)地址。這個(gè)步驟從重定向開始到引導(dǎo)回注冊(cè)地址之前，應(yīng)用方并不參與用戶身份校驗(yàn)和授權(quán)過程，確保第三方不可獲得用戶的真實(shí)帳號(hào)密碼。

　　第三步，用已授權(quán)令牌向服務(wù)提供方換取ATOK。第三方應(yīng)用需在服務(wù)端發(fā)起請(qǐng)求，用帳號(hào)密碼和上一步的令牌換取ATOK，這個(gè)步驟對(duì)用戶而言也是透明的。如果前兩步分別是讓服務(wù)提供方認(rèn)證應(yīng)用和用戶，那這步就是用戶和服務(wù)提供方再次認(rèn)證第三方應(yīng)用。因?yàn)橛脩魹g覽器將第二步的結(jié)果重定向到第三步，除非用戶DNS被劫持，否則就能確保重定向到的是合法的地址。曾經(jīng)我很困惑在用戶授權(quán)之后為何不直接返回ATOK而需要再次換取，估計(jì)是出于對(duì)ATOK的安全考慮，用戶瀏覽器一端存在太多的可能性讓ATOK泄漏，最安全的辦法還是讓第三方服務(wù)端來(lái)獲取和保管ATOK。

　　第四步，用ATOK作為令牌訪問受保護(hù)資源。很多時(shí)候，權(quán)限是有多種類別的。ATOK包含了某個(gè)用戶對(duì)某個(gè)應(yīng)用的授權(quán)憑據(jù)，準(zhǔn)確的說(shuō)，ATOK對(duì)應(yīng)用戶授權(quán)時(shí)所賦予的一系列權(quán)限的集合。所以在這一步，除了校驗(yàn)ATOK的合法性之外，服務(wù)提供方還需對(duì)該ATOK是否擁有足夠的權(quán)限執(zhí)行被保護(hù)操作進(jìn)行判斷。

　　單次簽名

　　在OAuth里，OAuth的相關(guān)請(qǐng)求都要做單次簽名，目的是防止OAuth的請(qǐng)求被篡改和重放。簽名當(dāng)然是拿應(yīng)用帳號(hào)的密碼來(lái)做簽名，其實(shí)就是對(duì)HTTP請(qǐng)求中所有OAuth相關(guān)的參數(shù)都連在一塊，使用密碼計(jì)算某種哈希值作為簽名。OAuth規(guī)范里描述了簽名的規(guī)則，那是相當(dāng)?shù)姆爆崱?fù)雜，足以嚇跑一大堆未經(jīng)世事的開發(fā)者。隨便找一個(gè)OAuth開放平臺(tái)的API文檔，我相信在OAuth授權(quán)流程有接近一半會(huì)在描述怎么產(chǎn)生簽名構(gòu)造一個(gè)合法的HTTP請(qǐng)求。有一對(duì)文字圖片描述還不夠，各開放平臺(tái)幾乎無(wú)一例外地提供各種開發(fā)語(yǔ)言下的SDK，為求盡量降低技術(shù)門檻。即使如此，不少開發(fā)者依然覺得，OAuth的簽名過程實(shí)在是太復(fù)雜了，而這些復(fù)雜也沒有帶來(lái)預(yù)期的好處。

　　重定向地址

　　為了防止有攻擊者偽造重定向地址騙取用戶授權(quán)，服務(wù)提供方應(yīng)對(duì)授權(quán)時(shí)的重定向地址進(jìn)行驗(yàn)證。所以注冊(cè)時(shí)，第三方應(yīng)提供重定向地址。服務(wù)提供方可以直接對(duì)重定向地址進(jìn)行等值判斷，但這樣的話就沒辦法讓第三方在授權(quán)過程中傳遞狀態(tài)，只能借助Cookie/Session之類的方式了。服務(wù)提供方也可以判斷重定向地址是否同一個(gè)域，這樣的話應(yīng)用方就可以在URI里傳遞少量狀態(tài)。對(duì)于一些沒有服務(wù)端的第三方Web應(yīng)用，由于代碼是公開的，將應(yīng)用的帳號(hào)密碼存在頁(yè)面里并不合適。OAuth則建議不使用重定向地址，讓用戶在授權(quán)后，把授權(quán)碼人工輸入到應(yīng)用中進(jìn)行下一步。記得有段時(shí)間FaWave也是這么添加新帳號(hào)的。

　　安全漏洞

　　OAuth曾爆了一個(gè)安全漏洞，攻擊者利用此漏洞可騙取用戶信任獲取非法的授權(quán)。

　　這個(gè)網(wǎng)頁(yè)有該漏洞的詳細(xì)說(shuō)明，流程如下：

　　

　　簡(jiǎn)單的說(shuō)，這個(gè)漏洞主要的關(guān)鍵是：

　　　　1. 部分服務(wù)提供方并未對(duì)重定向地址進(jìn)行合法性判斷，或者部分第三方的重定向地址會(huì)根據(jù)URI的參數(shù)再次重定向從而被攻擊者利用；

　　　　2.?RequestToken從未授權(quán)到已授權(quán)的狀態(tài)轉(zhuǎn)變時(shí)沒有變化，從而為攻擊者暴力訪問回調(diào)地址騙取ATOK提供可能；

　　對(duì)于第一點(diǎn)，攻擊者偽造重定向地址，即可騙得用戶對(duì)可靠第三方的授權(quán)，獲得ATOK

　　對(duì)于第二點(diǎn)，假如第一點(diǎn)不成立，那攻擊者可以用第一步的請(qǐng)求令牌構(gòu)造一個(gè)合法的重定向請(qǐng)求，并在用戶授權(quán)之后、瀏覽器重定向到合法重定向地址之前，進(jìn)行同樣操作執(zhí)行這個(gè)重定向操作，此時(shí)就看攻擊者和正常授權(quán)流程就存在競(jìng)爭(zhēng)關(guān)系。如果第三方先處理攻擊者的請(qǐng)求，攻擊者就獲得了最終的ATOK。

　　為了解決上述安全漏洞，OAuth更新了1.0a版本，主要改變就是第一步增加對(duì)重定向地址的簽名，和第二步與第三步之間增加一個(gè)隨機(jī)校驗(yàn)碼，使之與未授權(quán)的RequestToken有所區(qū)分。

?　　目前大部分的平臺(tái)都轉(zhuǎn)到了OAuth2。OAuth2雖并不兼容OAuth1，但基本原理是一樣的。

?

OAuth2的改變

　　OAuth2對(duì)比OAuth1，主要改變有下面幾點(diǎn)：

　　　　1. 取消繁瑣的簽名，全部改用HTTPS。

　　　　2. ATOK從原來(lái)的永久令牌變?yōu)榕R時(shí)令牌，增加RefreshToken

　　　　3. 取消獲取RequestToken的步驟

　　　　4. 提供了多種場(chǎng)景的授權(quán)流程

　　HTTPS

　　OAuth原有的簽名算法實(shí)在是太繁瑣了，嚇跑了不少開發(fā)者。對(duì)于服務(wù)提供方，也很不好實(shí)現(xiàn)，特別是單次簽名的實(shí)現(xiàn)，由于服務(wù)提供方要確保每次由客戶端生成的隨機(jī)碼不被重復(fù)利用，必須存儲(chǔ)每次請(qǐng)求發(fā)來(lái)的隨機(jī)碼，無(wú)論是對(duì)存儲(chǔ)還是校驗(yàn)都是一個(gè)難題。通常的做法是，存儲(chǔ)一段時(shí)間的隨機(jī)碼，這個(gè)時(shí)間需比RequestToken的過期時(shí)間要長(zhǎng)。這樣即使到時(shí)還有重放攻擊，RequestToken也已經(jīng)失效。

　　 OAuth2取消了簽名，改用HTTPS來(lái)加密，確保通信內(nèi)容不被第三方竊取。這個(gè)改變毫無(wú)疑問是降低了門檻，授權(quán)的流程被簡(jiǎn)化了。雖有少量人有異議，但OAuth2最大的異議是臨時(shí)的ATOK。

　　ATOK與RefreshToken

　　由于第三方應(yīng)用往往不重視ATOK的安全性，開發(fā)者為圖方便經(jīng)常把ATOK從后端發(fā)給前端頁(yè)面或者存在cookie中。由于OAuth1中ATOK幾乎是永久性的，即使發(fā)現(xiàn)ATOK被盜用，也只能讓用戶取消授權(quán)，這可能會(huì)造成一些其他的問題。OAuth2將ATOK改為臨時(shí)令牌，當(dāng)ATOK過期后，需要使用RefreshToken重新獲取新的ATOK，讓開發(fā)者郁悶的是，RefreshToken也不是永久性的，不同的服務(wù)提供方有不同的過期時(shí)間，相同的是，過期時(shí)間都不會(huì)太長(zhǎng)，頂多也就幾個(gè)月。

　　這個(gè)改變對(duì)很多第三方應(yīng)用是個(gè)坑爹的改變，原本他們幾乎都是拿ATOK作為OpenID來(lái)使用的（所以才有了各種ATOK被盜用的隱患），而到了OAuth2，ATOK已經(jīng)不能唯一標(biāo)識(shí)一個(gè)用戶了，他們要多做很多的東西才能維持用戶的身份，在使用ATOK訪問用戶資源時(shí)，步驟也是異常繁瑣。

　　雖然臨時(shí)ATOK這個(gè)改變很合理，但對(duì)開發(fā)者很不友好，今后會(huì)不會(huì)繼續(xù)改變，可以拭目以待。我個(gè)人覺得，這個(gè)問題其實(shí)是另外一個(gè)問題，那就是開發(fā)者對(duì)用戶帳號(hào)信息的安全意識(shí)太單薄，后面講OAuth的問題時(shí)再詳細(xì)討論。

　　授權(quán)流程

　　OAuth1流程比較復(fù)雜，盡管規(guī)范里有對(duì)多種場(chǎng)景的授權(quán)流程進(jìn)行不同的建議，但很多應(yīng)用和開放平臺(tái)最終都使用了同一種授權(quán)流程，結(jié)果產(chǎn)生了安全隱患（例如上面重定向地址的問題嗎）。OAuth2描述了四種授權(quán)場(chǎng)景，為這些場(chǎng)景下的授權(quán)流程提供指導(dǎo)。我只簡(jiǎn)單說(shuō)些要點(diǎn)和差異，詳細(xì)的說(shuō)明還是看官方文檔和各開放平臺(tái)的文檔穩(wěn)妥些。

　　(待續(xù))

轉(zhuǎn)載于:https://www.cnblogs.com/neutra/archive/2012/07/26/2609300.html

總結(jié)

以上是生活随笔為你收集整理的OAuth2授权原理的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。