OAuth 2.0 是什么

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

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

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

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

授權(quán)訪問(wèn)

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

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

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

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

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

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

OAuth 2.0 不能做什么

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

OAuth 2.0 授權(quán)過(guò)程

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

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

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

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

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

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

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

因?yàn)橘Y源擁有者通過(guò)瀏覽器與授權(quán)端點(diǎn)交互，所以也要通過(guò)瀏覽器來(lái)完成身份認(rèn)證。因此，有很多身份認(rèn)證技術(shù)可以用于用戶身份認(rèn)證流程。OAuth 沒(méi)有規(guī)定應(yīng)該使用哪種身份認(rèn)證技術(shù)，授權(quán)服務(wù)器可以自由選擇，例如用戶名/密碼、加密證書(shū)、安全令牌、聯(lián)合單點(diǎn)登錄或者其他方式。

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

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

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

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

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

bearer 令牌的使用權(quán)
OAuth 核心規(guī)范對(duì)bearer 令牌的使用做了規(guī)定，無(wú)論是誰(shuí)，只要持有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 個(gè)主要的角色：客戶端、授權(quán)服務(wù)器、資源擁有者以及受保護(hù)資源。這些組件分別負(fù)責(zé)OAuth 協(xié)議的不同部分，并且相互協(xié)作使OAuth 協(xié)議運(yùn)轉(zhuǎn)。

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

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

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

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

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

訪問(wèn)令牌

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

權(quán)限范圍

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

刷新令牌

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

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

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

授權(quán)許可

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

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

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

OAuth 是一個(gè)基于HTTP 的協(xié)議，但是與大多數(shù)基于HTTP 的協(xié)議不同，OAuth 中的交互并不總是通過(guò)簡(jiǎn)單的HTTP 請(qǐng)求和響應(yīng)來(lái)完成。

非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 來(lái)啟動(dòng)OAuth 流程，但它們是想將基于HTTP 的OAuth 組件直接搬到其他協(xié)議上去。

后端信道通信

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

前端信道通信

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

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

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

?在前面看到的授權(quán)碼許可中，客戶端需要將用戶重定向至授權(quán)端點(diǎn)，但是也需要將其請(qǐng)求的內(nèi)容信息傳遞給授權(quán)服務(wù)器。為此，客戶端向?yàn)g覽器發(fā)送一個(gè)HTTP 重定向。這個(gè)重定向的目標(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 請(qǐng)求一樣解析傳入的URL，從參數(shù)中獲取信息。在這個(gè)環(huán)節(jié)，授權(quán)服務(wù)器可以與資源擁有者進(jìn)行交互，通過(guò)瀏覽器執(zhí)行一系列HTTP 事務(wù)，對(duì)資源擁有者進(jìn)行身份認(rèn)證并請(qǐng)求其授權(quán)。當(dāng)需要給客戶端返回授權(quán)碼時(shí)，授權(quán)服務(wù)器也向?yàn)g覽器返回重定向響應(yīng)，但是這一次的重定向目標(biāo)是客戶端的redirect_uri。授權(quán)服務(wù)器也會(huì)在重定向的查詢參數(shù)中附帶信息。

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

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

?

總結(jié)

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

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