OAuth 2.0 是什么

OAuth 2.0 是一個授權(quán)協(xié)議，它允許軟件應(yīng)用代表（而不是充當(dāng)）資源擁有者去訪問資源擁有者的資源。應(yīng)用向資源擁有者請求授權(quán)，然后取得令牌（token），并用它來訪問資源。這一切都不需要應(yīng)用去充當(dāng)資源擁有者的身份，因?yàn)榱钆泼鞔_表示了被授予的訪問權(quán)。

作為一個授權(quán)框架，OAuth 關(guān)注的是如何讓一個系統(tǒng)組件獲取對另一個系統(tǒng)組件的訪問權(quán)限。在OAuth 的世界中，最常見的情形是客戶端應(yīng)用代表資源擁有者（通常是最終用戶）訪問受保護(hù)資源。需要關(guān)心如下組件。

• 資源擁有者有權(quán)訪問API，并能將API 訪問權(quán)限委托出去。資源擁有者一般是能使用瀏覽器的人。
• 受保護(hù)資源是資源擁有者有權(quán)限訪問的組件。這樣的組件有多種形式，但大多數(shù)情況下是某種形式的Web API。
• 客戶端是代表資源擁有者訪問受保護(hù)資源的軟件。在OAuth 中，只要軟件使用了受保護(hù)資源上的API，它就是客戶端。

?客戶端需要資源擁有者暴露出憑據(jù)，例如LDAP身份驗(yàn)證。

授權(quán)訪問

OAuth 協(xié)議的設(shè)計目的是：讓最終用戶通過OAuth 將他們在受保護(hù)資源上的部分權(quán)限委托給客戶端應(yīng)用，使客戶端應(yīng)用代表他們執(zhí)行操作。為實(shí)現(xiàn)這一點(diǎn)，OAuth 在系統(tǒng)中引入了另外一個組件：授權(quán)服務(wù)器。

受保護(hù)資源依賴授權(quán)服務(wù)器向客戶端頒發(fā)專用的安全憑據(jù)——OAuth 訪問令牌。為了獲取令牌，客戶端首先將資源擁有者引導(dǎo)至授權(quán)服務(wù)器，請求資源擁有者為其授權(quán)。授權(quán)服務(wù)器先對資源擁有者進(jìn)行身份認(rèn)證，然后一般會讓資源擁有者選擇是否對客戶端授權(quán)。客戶端可以請求授權(quán)功能或權(quán)限范圍的子集，該子集可能會被資源擁有者進(jìn)一步縮小。一旦授權(quán)請求被許可，客戶端就可以向授權(quán)服務(wù)器請求訪問令牌。按照資源擁有者的許可，客戶端可以使用該令牌對受保護(hù)資源上的API 進(jìn)行訪問?。在這個過程中，沒有將資源擁有者的憑據(jù)暴露給客戶端：資源擁有者向授權(quán)服務(wù)器進(jìn)行身份認(rèn)證的過程中所用的信息是獨(dú)立于客戶端交互的。

OAuth授權(quán)過程??

?授權(quán)委托：重要性及應(yīng)用

委托概念是OAuth 強(qiáng)大功能的根基。雖然OAuth 經(jīng)常被稱作授權(quán)協(xié)議（這是RFC 中給出的名稱），但它也是一個委托協(xié)議。通常，被委托的是用戶權(quán)限的子集，但是OAuth 本身并不承載或者傳遞權(quán)限。相反，它提供了一種方法，讓客戶端可以請求用戶將部分權(quán)限委托給自己。然后，用戶可以批準(zhǔn)這個委托請求。被批準(zhǔn)之后，客戶端就可以去執(zhí)行那些操作了。

委托協(xié)議和授權(quán)協(xié)議的區(qū)別是很重要的，因?yàn)?strong>OAuth 令牌中攜帶的授權(quán)信息對系統(tǒng)中的大部分組件是不透明的。只有受保護(hù)資源需要了解授權(quán)信息，只要它能從令牌中得知授權(quán)信息（既可以直接從令牌中獲取，也可以通過某種服務(wù)來獲取），它就可以按要求提供API 服務(wù)。

OAuth 2.0 不能做什么

• OAuth 沒有定義HTTP 協(xié)議之外的情形。由于使用bearer 令牌的OAuth 2.0 并不提供消息簽名，因此不應(yīng)該脫離HTTPS（TLS 上的HTTP）使用。機(jī)密信息需要在網(wǎng)絡(luò)上傳播，所以O(shè)Auth需要TLS 這樣的傳輸機(jī)制來保護(hù)這些信息。
• OAuth 不是身份認(rèn)證協(xié)議，盡管用戶確實(shí)存在，但OAuth 事務(wù)本身并不透露關(guān)于用戶的信息。
• OAuth 沒有定義用戶對用戶的授權(quán)機(jī)制，需要其他協(xié)議輔助，例如：User Managed Access 協(xié)議（將在第14 章中討論）就是為此而生，它規(guī)定了如何使用OAuth 構(gòu)建一個支持用戶對用戶授權(quán)的系統(tǒng)。
• OAuth 沒有定義授權(quán)處理機(jī)制。
• OAuth 沒有定義令牌格式。實(shí)際上，OAuth 協(xié)議明確聲明了令牌的內(nèi)容對客戶端是完全不透明的。
• OAuth 2.0 沒有定義加密方法。可以使用其他加密機(jī)制，例如：了JSON 對象簽名和加密（JOSE）規(guī)范套件。
• OAuth 2.0 不是單體協(xié)議。該規(guī)范被分成了多個定義和流程，每個定義和流程都有各自適用的場景。

OAuth 2.0 授權(quán)過程

OAuth 是一個復(fù)雜的安全協(xié)議，它需要不同的組件相互通信，OAuth 事務(wù)中的兩個重要步驟是頒發(fā)令牌和使用令牌。令牌表示授予客戶端的訪問權(quán)，它在OAuth 2.0 的各個部分都起到核心作用。盡管每個步驟的細(xì)節(jié)會因多種因素而異，但是一個規(guī)范的OAuth 事務(wù)包含以下事件。
(1) 資源擁有者向客戶端表示他希望客戶端代表他執(zhí)行一些任務(wù)
(2) 客戶端在授權(quán)服務(wù)器上向資源擁有者請求授權(quán)。
(3) 資源擁有者許可客戶端的授權(quán)請求。
(4) 客戶端接收到來自授權(quán)服務(wù)器的令牌。
(5) 客戶端向受保護(hù)資源出示令牌。

OAuth 2.0 授權(quán)許可的完整過程

授權(quán)碼許可中用到了一個臨時憑據(jù)——授權(quán)碼——來表示資源擁有者同意向客戶端授權(quán)。

（0）資源擁有者訪問客戶端應(yīng)用，并表明他希望客戶端代表自己去使用某一受保護(hù)資源。

（1）當(dāng)客戶端發(fā)現(xiàn)需要獲取一個新的OAuth 訪問令牌時，它會將資源擁有者重定向（WEB一般指HTTP重定向）至授權(quán)服務(wù)器，并附帶一個授權(quán)請求，表示它要向資源擁有者請求一些權(quán)限?。

（2）重定向響應(yīng)導(dǎo)致瀏覽器向授權(quán)服務(wù)器發(fā)送一個GET 請求，客戶端通過在發(fā)送給用戶的URL 中包含查詢參數(shù)，來標(biāo)識自己的身份和要請求的授權(quán)詳情，如權(quán)限范圍等。雖然請求并不是由客戶端直接發(fā)出的，但授權(quán)服務(wù)器會解析這些參數(shù)并做出適當(dāng)?shù)姆磻?yīng)。

（3）授權(quán)服務(wù)器會要求用戶進(jìn)行身份認(rèn)證。用戶身份認(rèn)證直接在用戶（和用戶的瀏覽器）與授權(quán)服務(wù)器之間進(jìn)行，這個過程對客戶端應(yīng)
用不可見。

因?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)登錄或者其他方式。

（4）用戶向客戶端應(yīng)用授權(quán)。在這一步，資源擁有者選擇將一部分權(quán)限授予客戶端應(yīng)用，授權(quán)服務(wù)器提供了許多不同的選項來實(shí)現(xiàn)這一點(diǎn)

（5）授權(quán)服務(wù)器將用戶重定向回客戶端應(yīng)用，一般通過redirect_uri實(shí)現(xiàn)，并且?guī)?strong>授權(quán)碼。它是一次性的憑據(jù)，表示用戶授權(quán)決策的結(jié)果。客戶端會在接收到請求之后解析該參數(shù)以獲取授權(quán)碼，并在下一步使用該授權(quán)碼。

（6）現(xiàn)在客戶端已經(jīng)得到授權(quán)碼，它可以將其發(fā)送給授權(quán)服務(wù)器的令牌端點(diǎn)。

（7）授權(quán)服務(wù)器接收該請求，如果請求有效，則頒發(fā)令牌。授權(quán)服務(wù)器需要執(zhí)行多個步驟以確保請求是合法的。首先，它要驗(yàn)證客戶端憑據(jù)（通過Authorization 頭部傳遞）以確定是哪個客戶端請求授權(quán)。然后，從請求主體中讀取code 參數(shù)的值，并從中獲取關(guān)于該授權(quán)碼的信息，包括發(fā)起初始授權(quán)請求的是哪個客戶端，執(zhí)行授權(quán)的是哪個用戶，授權(quán)的內(nèi)容是什么。如果授權(quán)碼有效且尚未使用過，而且發(fā)起該請求的客戶端與最初發(fā)起授權(quán)請求的客戶端相同，則授權(quán)服務(wù)器會生成一個新的訪問令牌并返回給客戶端。

（8）客戶端可以解析令牌響應(yīng)并從中獲取令牌的值來訪問受保護(hù)資源。。令牌響應(yīng)中還可以包含一個刷新令牌（用于獲取新的訪問令牌而不必重新請求授權(quán)），以及一些關(guān)于訪問令牌的附加信息，比如令牌的權(quán)限范圍和過期時間。客戶端可以將訪問令牌存儲在一個安全的地方，以便以后在用戶不在場時也能夠隨時使用。

bearer 令牌的使用權(quán)
OAuth 核心規(guī)范對bearer 令牌的使用做了規(guī)定，無論是誰，只要持有bearer 令牌就有權(quán)使用它。

客戶端出示令牌的方式有多種，備受推薦的方式：使用Authorization 頭部。

GET /resource HTTP/1.1
Host: localhost:9002
Accept: application/json
Connection: keep-alive
Authorization: Bearer 987tghjkiu6trfghjuytrghj

OAuth 中的角色：客戶端、授權(quán)服務(wù)器、資源擁有者、受保護(hù)資源

OAuth 系統(tǒng)中有4 個主要的角色：客戶端、授權(quán)服務(wù)器、資源擁有者以及受保護(hù)資源。這些組件分別負(fù)責(zé)OAuth 協(xié)議的不同部分，并且相互協(xié)作使OAuth 協(xié)議運(yùn)轉(zhuǎn)。

?OAuth 客戶端是代表資源擁有者訪問受保護(hù)資源的軟件，它使用OAuth 來獲取訪問權(quán)限。它的職責(zé)主要是從授權(quán)服務(wù)器
獲取令牌以及在受保護(hù)資源上使用令牌。客戶端不需要理解令牌，也不需要查看令牌的內(nèi)容。相反，客戶端只需要將令牌視為一個不透明的字符串即可。OAuth 客戶端可以是Web 應(yīng)用、原生應(yīng)用，甚至瀏覽器內(nèi)的JavaScript 應(yīng)用。

受保護(hù)資源能夠通過HTTP 服務(wù)器進(jìn)行訪問，在訪問時需要OAuth 訪問令牌。受保護(hù)資源需要驗(yàn)證收到的令牌，并決定是否響應(yīng)以及如何響應(yīng)請求。在OAuth 架構(gòu)中，受保護(hù)資源對是否認(rèn)可令牌擁有最終決定權(quán)。

資源擁有者是有權(quán)將訪問權(quán)限授權(quán)給客戶端的主體。與OAuth 系統(tǒng)中的其他組件不同，資源擁有者不是軟件。在大多數(shù)情況下，資源擁有者是一個人，他使用客戶端軟件訪問受他控制的資源。

OAuth 授權(quán)服務(wù)器是一個HTTP 服務(wù)器，它在OAuth 系統(tǒng)中充當(dāng)中央組件。授權(quán)服務(wù)器對資源擁有者和客戶端進(jìn)行身份認(rèn)證，讓資源擁有者向客戶端授權(quán)、為客戶端頒發(fā)令牌。某些授權(quán)服務(wù)器還會提供額外的功能，例如令牌內(nèi)省、記憶授權(quán)決策。

OAuth 的組件：令牌、權(quán)限范圍和授權(quán)許可

訪問令牌

OAuth 訪問令牌，有時也簡稱為令牌，由授權(quán)服務(wù)器頒發(fā)給客戶端，表示客戶端已被授予權(quán)限。OAuth 并沒有定義令牌本身的格式和內(nèi)容，但它總是代表著：客戶端請求的訪問權(quán)限、對客戶端授權(quán)的資源擁有者，以及被授予的權(quán)限（通常包含一些受保護(hù)資源標(biāo)識）。
OAuth 令牌對于客戶端來說是不透明的，也就是說客戶端不需要（通常也不能）查看令牌內(nèi)容。客戶端要做的就是持有令牌，向授權(quán)服務(wù)器請求令牌，并向受保護(hù)資源出示令牌。OAuth 令牌并非對系統(tǒng)中的所有組件都不透明：授權(quán)服務(wù)器的任務(wù)是頒發(fā)令牌，受保護(hù)資源的任務(wù)則是驗(yàn)證令牌。因此，它們都需要理解令牌本身，并知道其含義。然而，客戶端對這一切一無所知。這使得客戶端簡單得多，同時也使得授權(quán)服務(wù)器和受保護(hù)資源可以十分靈活地部署令牌。

權(quán)限范圍

OAuth的權(quán)限范圍表示一組訪問受保護(hù)資源的權(quán)限。OAuth協(xié)議中使用字符串表示權(quán)限范圍，可以用空格分隔的列表將它們合并為一個集合。因此，權(quán)限范圍的值不能包含空格。OAuth 并沒有規(guī)定權(quán)限范圍值的格式和結(jié)構(gòu)。

刷新令牌

OAuth 刷新令牌在概念上與訪問令牌很相似，它也是由授權(quán)服務(wù)器頒發(fā)給客戶端的令牌，客戶端也不知道或不關(guān)心該令牌的內(nèi)容。但不同的是，該令牌從來不會被發(fā)送給受保護(hù)資源。相反，客戶端使用刷新令牌向授權(quán)服務(wù)器請求新的訪問令牌，而不需要用戶參與。

?為什么客戶端需要刷新令牌？在OAuth 中，訪問令牌隨時可能失效。令牌有可能被用戶撤銷，也可能過期，或者其他系統(tǒng)導(dǎo)致令牌失效。訪問令牌失效后，客戶端在使用時會收到錯誤響應(yīng)。OAuth 2.0 提供了讓令牌自動過期的選項，但是我們需要在用戶不在場的時候仍然能訪問資源。現(xiàn)在，刷新令牌取代了永不過期的訪問令牌，但它的作用不是訪問資源，而是獲取新的訪問令牌來訪問資源。這種做法以一種獨(dú)立但互補(bǔ)的方式，限制了刷新令牌和訪問令牌的暴露范圍。

刷新令牌還可以讓客戶端縮小它的權(quán)限范圍。如果客戶端被授予A、B、C 三個權(quán)限范圍，但是它知道某特定請求只需要A 權(quán)限范圍，則它可以使用刷新令牌重新獲取一個僅包含A 權(quán)限范圍的訪問令牌。這讓足夠智能的客戶端可以遵循最小權(quán)限安全原則。

授權(quán)許可

授權(quán)許可是OAuth 協(xié)議中的權(quán)限獲取方法，OAuth 客戶端用它來獲取受保護(hù)資源的訪問權(quán)限，成功之后客戶端會得到一個令牌。這可能是OAuth 2.0 中最令人困惑的術(shù)語之一，因?yàn)樗缺硎居脩羰跈?quán)所用的特定方式，也表示授權(quán)這個行為本身。前面詳細(xì)介紹過的授權(quán)碼許可類型加劇了這種困惑，因?yàn)殚_發(fā)人員有時候會看見傳回給客戶端的授權(quán)碼，并誤以為這個授權(quán)碼（僅授權(quán)碼）就是授權(quán)許可。雖然授權(quán)碼確實(shí)代表用戶的授權(quán)決策，但它不是授權(quán)許可本身。相反，整個OAuth 流程才是授權(quán)許可：客戶端將用戶重定向至授權(quán)端點(diǎn)，然后接收授權(quán)碼，最后用授權(quán)碼換取令牌。

換句話說，授權(quán)許可就是獲取令牌的方式。在本書中，就像在OAuth 社區(qū)中一樣，會偶爾將其稱為OAuth 協(xié)議的一個流程。OAuth 協(xié)議中有多種授權(quán)許可方法，并且各有特點(diǎn)。

OAuth 的角色與組件間的交互：后端信道、前端信道和端點(diǎn)

OAuth 是一個基于HTTP 的協(xié)議，但是與大多數(shù)基于HTTP 的協(xié)議不同，OAuth 中的交互并不總是通過簡單的HTTP 請求和響應(yīng)來完成。

非HTTP 信道之上的OAuth
雖然OAuth 是基于HTTP 的協(xié)議，但已有很多規(guī)范定義了如何將OAuth 流程中的不同部分遷移到非HTTP 協(xié)議上。例如，已經(jīng)有標(biāo)準(zhǔn)草案提出了如何在通用安全服務(wù)應(yīng)用程序接口（GSS-API）和受限應(yīng)用程序協(xié)議（CoAP）上使用OAuth 令牌。在這些草案中，仍然可以使用HTTP 來啟動OAuth 流程，但它們是想將基于HTTP 的OAuth 組件直接搬到其他協(xié)議上去。

后端信道通信

OAuth 流程中的很多部分都使用標(biāo)準(zhǔn)的HTTP 請求和響應(yīng)格式來相互通信。由于這些請求通常都發(fā)生在資源擁有者和用戶代理的可見范圍之外，因此它們統(tǒng)稱為后端信道通信。
這些請求和響應(yīng)使用了所有常規(guī)的HTTP 機(jī)制來通信：頭部、查詢參數(shù)、HTTP 方法和HTTP主體都能承載對OAuth 事務(wù)至關(guān)重要的信息。請注意，由于多數(shù)簡單的Web API 只需要客戶端開發(fā)人員關(guān)注響應(yīng)主體，這可能包含了你不熟悉的一些HTTP 機(jī)制。
授權(quán)服務(wù)器提供了一個授權(quán)端點(diǎn)，供客戶端請求訪問令牌和刷新令牌。客戶端直接向該端點(diǎn)發(fā)出請求，攜帶一組表單格式的參數(shù)，授權(quán)服務(wù)器解析并處理這些參數(shù)。然后授權(quán)服務(wù)器返回一個代表令牌的JSON 對象。

前端信道通信

在標(biāo)準(zhǔn)的HTTP 通信中，HTTP 客戶端向服務(wù)器直接發(fā)送一個請求，其中包含頭部、查詢參數(shù)、主體及其他信息。然后HTTP 服務(wù)器可以查看這些信息，并決定如何響應(yīng)請求，響應(yīng)中包含頭部、主體及其他信息。然而，在OAuth 中，在某些情況下兩個組件是無法直接相互發(fā)送請求和響應(yīng)的，例如客戶端與授權(quán)服務(wù)器的授權(quán)端點(diǎn)交互的時候。前端信道通信就是一種間接通信方法，它將Web 瀏覽器作為媒介，使用HTTP 請求實(shí)現(xiàn)兩個系統(tǒng)間的間接通信。

這一技術(shù)隔離了瀏覽器兩端的會話，實(shí)現(xiàn)了跨安全域工作。例如，如果用戶需要向其中一個組件進(jìn)行身份認(rèn)證，并不需要將憑據(jù)暴露給另一個系統(tǒng)。這樣，在保持信息隔離的情況下，仍然能讓用戶在通信中發(fā)揮作用。

兩個不直接交互的軟件是如何實(shí)現(xiàn)通信的呢？前端信道通信是這樣實(shí)現(xiàn)的：發(fā)起方在一個URL 中附加參數(shù)并指示瀏覽器跳轉(zhuǎn)至該URL。然后接收方可以解析該入站URL（由瀏覽器跳轉(zhuǎn)來的），并使用其中包含的信息。之后，接收方可以將瀏覽器重定向至發(fā)起方托管的URL，并使用同樣的方式在URL 中附加參數(shù)。這樣，兩個軟件就以Web 瀏覽器為媒介，實(shí)現(xiàn)了間接通信。這意味著每個前端信道的請求和響應(yīng)實(shí)際上是一對HTTP 請求/響應(yīng)事務(wù)。

?在前面看到的授權(quán)碼許可中，客戶端需要將用戶重定向至授權(quán)端點(diǎn)，但是也需要將其請求的內(nèi)容信息傳遞給授權(quán)服務(wù)器。為此，客戶端向?yàn)g覽器發(fā)送一個HTTP 重定向。這個重定向的目標(biāo)是授權(quán)服務(wù)器的URL，并且其查詢參數(shù)中附有特定參數(shù)。

HTTP 302 Found
Location: http://localhost:9001/authorize?client_id=oauth-client-1&response_type=code&state=843hi43824h42tj

?授權(quán)服務(wù)器可以像處理一般的HTTP 請求一樣解析傳入的URL，從參數(shù)中獲取信息。在這個環(huán)節(jié)，授權(quán)服務(wù)器可以與資源擁有者進(jìn)行交互，通過瀏覽器執(zhí)行一系列HTTP 事務(wù)，對資源擁有者進(jìn)行身份認(rèn)證并請求其授權(quán)。當(dāng)需要給客戶端返回授權(quán)碼時，授權(quán)服務(wù)器也向?yàn)g覽器返回重定向響應(yīng)，但是這一次的重定向目標(biāo)是客戶端的redirect_uri。授權(quán)服務(wù)器也會在重定向的查詢參數(shù)中附帶信息。

HTTP 302 Found
Location: http://localhost:9000/oauth_callback?code=23ASKBWe4&state=843hi43824h42tj

?所有通過前端信道傳遞的信息都可供瀏覽器訪問，既能被讀取，也可能在最終請求發(fā)出之前被篡改。OAuth 協(xié)議已經(jīng)考慮到這一點(diǎn)，它限制了能通過前端信道傳輸?shù)男畔㈩悇e，并確保只要是通過前端信道傳輸?shù)男畔?#xff0c;就不能在授權(quán)任務(wù)中單獨(dú)使用。授權(quán)碼不能被瀏覽器直接使用，相反它必須通過后端信道與客戶端憑據(jù)一起出示。在有些協(xié)議中，比如OpenID Connect，要求客戶端或者授權(quán)服務(wù)器對前端信道中傳輸?shù)南⒑灻?#xff0c;通過這樣的安全機(jī)制增加一層保護(hù)。

?

總結(jié)

以上是生活随笔為你收集整理的OAuth2（一）——核心概念的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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