思維導(dǎo)圖
前言
OAuth 2.0定義了4種許可類型，分別適用于不同的應(yīng)用類型，而不是單單定義一種復(fù)雜的方法來適應(yīng)不同的部署模型
OAuth 2.0已經(jīng)是互聯(lián)網(wǎng)上首選的授權(quán)協(xié)議。它被廣泛使用仲锄，從大型互聯(lián)網(wǎng)公司到小型創(chuàng)業(yè)公司霞丧，幾乎所有的地方都在使用它呢岗。
第 1 章 OAuth 2.0是什么，為什么要關(guān)心它
OAuth是一個(gè)安全協(xié)議蛹尝，用于保護(hù)全球范圍內(nèi)大量且在不斷增長的Web API
用于連接不同的網(wǎng)站后豫，還支持原生應(yīng)用和移動(dòng)應(yīng)用與云服務(wù)之間的連接。它是各領(lǐng)域標(biāo)準(zhǔn)協(xié)議中的安全層
1.1 OAuth 2.0是什么
OAuth 2.0是一個(gè)授權(quán)協(xié)議突那，它允許軟件應(yīng)用代表（而不是充當(dāng)）資源擁有者去訪問資源擁有者的資源挫酿。應(yīng)用向資源擁有者請求授權(quán)，然后取得令牌（token）愕难，并用它來訪問資源早龟。這一切都不需要應(yīng)用去充當(dāng)資源擁有者的身份惫霸，因?yàn)榱钆泼鞔_表示了被授予的訪問權(quán)。
OAuth 2.0框架能讓第三方應(yīng)用以有限的權(quán)限訪問HTTP服務(wù)葱弟，可以通過構(gòu)建資源擁有者與HTTP服務(wù)間的許可交互機(jī)制壹店，讓第三方應(yīng)用代表資源擁有者訪問服務(wù)，或者通過授予權(quán)限給第三方應(yīng)用芝加，讓其代表自己訪問服務(wù)茫打。
作為一個(gè)授權(quán)框架，OAuth關(guān)注的是如何讓一個(gè)系統(tǒng)組件獲取對另一個(gè)系統(tǒng)組件的訪問權(quán)限
需要關(guān)心如下組件
- 資源擁有者有權(quán)訪問API妖混，并能將API訪問權(quán)限委托出去
- 受保護(hù)資源是資源擁有者有權(quán)限訪問的組件
- 客戶端是代表資源擁有者訪問受保護(hù)資源的軟件
- 整個(gè)系統(tǒng)的目標(biāo)是：讓客戶端為資源擁有者訪問受保護(hù)資源
圖 1-2 代表資源擁有者連接客戶端
1.3 授權(quán)訪問
OAuth協(xié)議的設(shè)計(jì)目的是：讓最終用戶通過OAuth將他們在受保護(hù)資源上的部分權(quán)限委托給客戶端應(yīng)用老赤，使客戶端應(yīng)用代表他們執(zhí)行操作。
為實(shí)現(xiàn)這一點(diǎn)制市，OAuth在系統(tǒng)中引入了另外一個(gè)組件：授權(quán)服務(wù)器
圖 1-7 OAuth授權(quán)服務(wù)器自動(dòng)發(fā)送服務(wù)專用的密碼
受保護(hù)資源依賴授權(quán)服務(wù)器向客戶端頒發(fā)專用的安全憑據(jù)——OAuth訪問令牌
客戶端首先將資源擁有者引導(dǎo)至授權(quán)服務(wù)器抬旺，請求資源擁有者為其授權(quán)
然后一般會(huì)讓資源擁有者選擇是否對客戶端授權(quán)
一旦授權(quán)請求被許可，客戶端就可以向授權(quán)服務(wù)器請求訪問令牌祥楣。按照資源擁有者的許可开财，客戶端可以使用該令牌對受保護(hù)資源上的API進(jìn)行訪問
圖 1-8 完整的OAuth工作過程
OAuth系統(tǒng)常遵循TOFU原則：首次使用時(shí)信任（trust on first use）。在TOFU模型中误褪，需要用戶在第一次運(yùn)行時(shí)進(jìn)行安全決策责鳍，而且并不為安全決策預(yù)設(shè)任何先決條件或者配置，僅提示用戶做出決策兽间。這個(gè)過程可以簡單到只是詢問用戶“要連接到新的應(yīng)用嗎”
因?yàn)橐笥脩粼谝粋€(gè)上下文環(huán)境中做出安全決策具有很強(qiáng)的靈活性历葛，而不斷地要求用戶做決策會(huì)讓人疲倦，TOFU方法在這兩者間實(shí)現(xiàn)了良好的平衡
如果用上TOFU方法嘀略，就可以在上述的兩個(gè)名單中間增加一個(gè)灰名單恤溶，在這個(gè)名單中，會(huì)優(yōu)先考慮用戶在運(yùn)行時(shí)做出的信任決策帜羊。會(huì)有一定的策略來記錄和審查這些用戶決策咒程，以使風(fēng)險(xiǎn)最小化。通過灰名單功能讼育，系統(tǒng)的可擴(kuò)展性得到了極大提升帐姻，同時(shí)又不犧牲安全性。
1.4 OAuth 2.0：優(yōu)點(diǎn)奶段、缺點(diǎn)和丑陋的方面
OAuth 2.0的設(shè)計(jì)中有一個(gè)重要的假設(shè)饥瓷，就是不受控的客戶端總是比授權(quán)服務(wù)器或者受保護(hù)資源多出好幾個(gè)數(shù)量級
OAuth令牌提供了一種比密碼略復(fù)雜的機(jī)制，但如果使用得當(dāng)忧饭，其安全性要比密碼高很多扛伍。
圖 1-10 OAuth生態(tài)系統(tǒng)中各組件的相對數(shù)量
1.5 OAuth 2.0不能做什么
由于OAuth被定義為一個(gè)框架
核心規(guī)范詳述了一系列獲取訪問令牌的方法筷畦；還包括其伴隨規(guī)范中定義的bearer令牌
該規(guī)范規(guī)定了這種令牌的用法词裤。獲取令牌和使用令牌這兩個(gè)環(huán)節(jié)是OAuth的基本要素
OAuth沒有定義HTTP協(xié)議之外的情
OAuth沒有定義用戶對用戶的授權(quán)機(jī)制
要使資源擁有者向另一個(gè)用戶授權(quán)刺洒，僅使用OAuth是不行的。但這種授權(quán)并不罕見吼砂，User Managed Access協(xié)議（將在第14章中討論）就是為此而生逆航，它規(guī)定了如何使用OAuth構(gòu)建一個(gè)支持用戶對用戶授權(quán)的系統(tǒng)。
OAuth沒有定義令牌格式渔肩。實(shí)際上因俐，OAuth協(xié)議明確聲明了令牌的內(nèi)容對客戶端是完全不透明的。
令牌的授權(quán)服務(wù)器和接收令牌的受保護(hù)資源仍然需要理解令牌周偎。這個(gè)層面的互操作性要求催生了JSON Web Token （JWT）格式和令牌內(nèi)省協(xié)議抹剩，這將在第11章討論。雖然令牌本身對客戶端還是不透明的蓉坎，但現(xiàn)在它的格式能被其他組件理解澳眷。
OAuth無意用一個(gè)大而全的協(xié)議去解決安全系統(tǒng)所有方面的問題，而是只專注于一件事情蛉艾，把剩下的問題留給其他組件钳踊，讓它們各專所長。雖然還有很多議題不在OAuth范圍之內(nèi)勿侯，但它提供了一個(gè)堅(jiān)實(shí)的基礎(chǔ)拓瞪，可以基于它構(gòu)建其他更具針對性的工具，從而使安全架構(gòu)設(shè)計(jì)更加完善助琐。
1.6 小結(jié)
Auth是一個(gè)應(yīng)用廣泛的安全標(biāo)準(zhǔn)孕惜，它提供了一種安全訪問受保護(hù)資源的方式，特別適用于Web API
2.1 OAuth 2.0協(xié)議概覽：獲取和使用令牌
Auth事務(wù)中的兩個(gè)重要步驟是頒發(fā)令牌和使用令牌卡辰。令牌表示授予客戶端的訪問權(quán)悄谐，它在OAuth 2.0的各個(gè)部分都起到核心作用。
一個(gè)規(guī)范的OAuth事務(wù)包含以下事件
（1） 資源擁有者向客戶端表示他希望客戶端代表他執(zhí)行一些任務(wù)（例如“從該服務(wù)下載我的照片矢空，我想把它們打印出來”）
（2） 客戶端在授權(quán)服務(wù)器上向資源擁有者請求授權(quán)
（3） 資源擁有者許可客戶端的授權(quán)請求航罗。
（4） 客戶端接收到來自授權(quán)服務(wù)器的令牌。
（5） 客戶端向受保護(hù)資源出示令牌
2.2 OAuth 2.0授權(quán)許可的完整過程
授權(quán)碼許可中用到了一個(gè)臨時(shí)憑據(jù)——授權(quán)碼——來表示資源擁有者同意向客戶端授權(quán)屁药，如圖2-1所示粥血。
圖 2-1 授權(quán)碼許可的詳細(xì)過程
為了最大限度地保持靈活性，OAuth協(xié)議去除了真實(shí)API系統(tǒng)的很多細(xì)節(jié)酿箭。具體來說复亏，OAuth沒有規(guī)定客戶端如何知悉與受保護(hù)資源交互的方式，或者客戶端如何發(fā)現(xiàn)受保護(hù)資源對應(yīng)的授權(quán)服務(wù)器缭嫡。這些問題一般都由建立在OAuth之上的其他協(xié)議以標(biāo)準(zhǔn)方式解決缔御，例如OpenID Connect和User Managed Access（UMA）
當(dāng)客戶端發(fā)現(xiàn)需要獲取一個(gè)新的OAuth訪問令牌時(shí)，它會(huì)將資源擁有者重定向至授權(quán)服務(wù)器妇蛀，并附帶一個(gè)授權(quán)請求耕突，表示它要向資源擁有者請求一些權(quán)限（如圖2-2所示）笤成。例如，為了能讀取照片眷茁，照片打印服務(wù)可以向照片存儲(chǔ)服務(wù)請求訪問權(quán)限
圖 2-2 將資源擁有者引導(dǎo)至授權(quán)服務(wù)器以啟動(dòng)授權(quán)流程
然后炕泳，授權(quán)服務(wù)器會(huì)要求用戶進(jìn)行身份認(rèn)證。這一步對確認(rèn)資源擁有者的身份以及能向客戶端授予哪些權(quán)限來說至關(guān)重要
圖 2-3 資源擁有者登錄
因?yàn)橘Y源擁有者通過瀏覽器與授權(quán)端點(diǎn)交互上祈，所以也要通過瀏覽器來完成身份認(rèn)證培遵。因此，有很多身份認(rèn)證技術(shù)可以用于用戶身份認(rèn)證流程登刺。OAuth沒有規(guī)定應(yīng)該使用哪種身份認(rèn)證技術(shù)籽腕，授權(quán)服務(wù)器可以自由選擇，例如用戶名/密碼纸俭、加密證書节仿、安全令牌、聯(lián)合單點(diǎn)登錄或者其他方式
授權(quán)服務(wù)器可以允許用戶拒絕一部分或者全部權(quán)限范圍掉蔬，也可以讓用戶批準(zhǔn)或者拒絕整個(gè)授權(quán)請求
圖 2-4 資源擁有者批準(zhǔn)客戶端的授權(quán)請求
圖 2-5 將授權(quán)碼發(fā)送給客戶端
這一步采用HTTP重定向的方式廊宪，回到客戶端的redirect_uri。 HTTP 302 Found Location: http://localhost:9000/oauth_callback?code=8V1pr0rJ&state=Lwt50DDQKUB8U7jtfLQCVGDL9cnmwHH1 這又會(huì)導(dǎo)致瀏覽器向客戶端發(fā)出如下請求女轿。 GET /callback?code=8V1pr0rJ&state=Lwt50DDQKUB8U7jtfLQCVGDL9cnmwHH1 HTTP/1.1 Host: localhost:9000
由于使用的是授權(quán)碼許可類型箭启，因此該重定向鏈接中包含一個(gè)特殊的查詢參數(shù)code。這個(gè)參數(shù)的值被稱為授權(quán)碼蛉迹，它是一次性的憑據(jù)傅寡，表示用戶授權(quán)決策的結(jié)果”本龋客戶端會(huì)在接收到請求之后解析該參數(shù)以獲取授權(quán)碼荐操，并在下一步使用該授權(quán)碼≌洳撸客戶端還會(huì)檢查state參數(shù)值是否與它在前一個(gè)步驟中發(fā)送的值匹配
現(xiàn)在客戶端已經(jīng)得到授權(quán)碼托启，它可以將其發(fā)送給授權(quán)服務(wù)器的令牌端點(diǎn)
圖 2-6 客戶端將授權(quán)碼和自己的憑據(jù)發(fā)送給授權(quán)服務(wù)器
- 授權(quán)服務(wù)器接收該請求，如果請求有效攘宙，則頒發(fā)令牌（如圖2-7所示）屯耸。授權(quán)服務(wù)器需要執(zhí)行多個(gè)步驟以確保請求是合法的
圖 2-7 客戶端接收訪問令牌
OAuth核心規(guī)范對bearer令牌的使用做了規(guī)定，無論是誰蹭劈，只要持有bearer令牌就有權(quán)使用它疗绣。除非特別注明，本書中所有的示例都使用bearer令牌铺韧。bearer令牌具有特殊的安全屬性
有了令牌多矮，客戶端就可以在訪問受保護(hù)資源時(shí)出示令牌
客戶端出示令牌的方式有多種，本例中將使用備受推薦的方式：使用Authorization頭部哈打。
受保護(hù)資源可以從頭部中解析出令牌塔逃，判斷它是否有效讯壶，從中得知授權(quán)者是誰以及授權(quán)內(nèi)容，然后返回響應(yīng)
2.4 OAuth的組件：令牌患雏、權(quán)限范圍和授權(quán)許可
Auth刷新令牌在概念上與訪問令牌很相似鹏溯，它也是由授權(quán)服務(wù)器頒發(fā)給客戶端的令牌罢维，客戶端也不知道或不關(guān)心該令牌的內(nèi)容淹仑。但不同的是，該令牌從來不會(huì)被發(fā)送給受保護(hù)資源肺孵。相反匀借，客戶端使用刷新令牌向授權(quán)服務(wù)器請求新的訪問令牌，而不需要用戶參與
刷新令牌還可以讓客戶端縮小它的權(quán)限范圍平窘。如果客戶端被授予A吓肋、B、C三個(gè)權(quán)限范圍瑰艘，但是它知道某特定請求只需要A權(quán)限范圍是鬼，則它可以使用刷新令牌重新獲取一個(gè)僅包含A權(quán)限范圍的訪問令牌。這讓足夠智能的客戶端可以遵循最小權(quán)限安全原則
