瀏覽器提供了各種持久化數(shù)據(jù)的解決方案。當(dāng)存儲(chǔ)令牌時(shí)，您應(yīng)該權(quán)衡存儲(chǔ)選擇與安全風(fēng)險(xiǎn)。
譯自Best Practices for Storing Access Tokens in the Browser。
web應(yīng)用程序不是靜態(tài)站點(diǎn)，而是靜態(tài)內(nèi)容和動(dòng)態(tài)內(nèi)容的精心組合。更常見(jiàn)的是，web應(yīng)用程序邏輯在瀏覽器中運(yùn)行。與從服務(wù)器獲取所有內(nèi)容不同，應(yīng)用程序在瀏覽器中運(yùn)行JAVAScript，從后端API獲取數(shù)據(jù)，并相應(yīng)地更新web應(yīng)用程序呈現(xiàn)。
為了保護(hù)數(shù)據(jù)訪問(wèn)，組織應(yīng)該采用OAuth 2.0。通過(guò)OAuth 2.0，JavaScript應(yīng)用程序需要在對(duì)API的每個(gè)請(qǐng)求中添加訪問(wèn)令牌。出于可用性原因，JavaScript應(yīng)用程序通常不會(huì)按需請(qǐng)求訪問(wèn)令牌，而是存儲(chǔ)它。問(wèn)題是，如何在JavaScript中獲取這樣的訪問(wèn)令牌？當(dāng)您獲取一個(gè)令牌時(shí)，應(yīng)用程序應(yīng)該在哪里存儲(chǔ)令牌，以便在需要時(shí)將其添加到請(qǐng)求中？
本文討論了瀏覽器中可用的各種存儲(chǔ)解決方案，并突出了與每種選擇相關(guān)的安全風(fēng)險(xiǎn)。在審查威脅之后，它描述了一種解決方案，以提供最佳的瀏覽器安全選項(xiàng)，用于必須與OAuth保護(hù)的API集成的JavaScript應(yīng)用程序。
獲取訪問(wèn)令牌
在應(yīng)用程序可以存儲(chǔ)訪問(wèn)令牌之前，它需要先獲取一個(gè)令牌。當(dāng)前的最佳實(shí)踐建議通過(guò)“授權(quán)碼流”這一方式來(lái)獲取訪問(wèn)令牌: 授權(quán)碼流是一個(gè)兩步流程，首先從用戶那里收集一個(gè)授權(quán)許可——授權(quán)碼，然后應(yīng)用程序在后臺(tái)通道中用授權(quán)碼交換訪問(wèn)令牌。這個(gè)請(qǐng)求稱(chēng)為令牌請(qǐng)求，例子如下:
const accessToken = awAIt fetch(OAuthServerTokenEndpoint, {
method: "POST",
// token request with authorization code and PKCE
// submits data in as x-www-form-urlencoded encoded format
body: new URLSearchParams({
client_id: "example-client",
grant_type: "authorization_code",
code: authorization_code,
code_verifier: pkce_code_verifier
})
})
// server responds with JSON object
.then (response => response.json())
.then (tokenResponse => {
// parse access token from response
if (tokenResponse.accessToken) {
return tokenResponse.accessToken;
} // else handle error response
})
.catch(
// handle.NETwork error
)
請(qǐng)注意，任何人都可以檢查瀏覽器加載的資源，包括任何JavaScript代碼。因此，任何用JavaScript實(shí)現(xiàn)的OAuth客戶端都被認(rèn)為是一個(gè)公開(kāi)客戶端——一個(gè)無(wú)法保密的客戶端，因此在令牌請(qǐng)求期間無(wú)法進(jìn)行身份驗(yàn)證。然而，代碼交換的證明密鑰(Proof Key for Code Exchange，PKCE)提供了一種方法來(lái)確保公開(kāi)客戶端的授權(quán)碼流的安全性。為了減輕與授權(quán)碼相關(guān)的風(fēng)險(xiǎn)，在使用授權(quán)碼流時(shí)，始終應(yīng)用PKCE。
瀏覽器威脅
跨站請(qǐng)求偽造(CSRF)
在跨站請(qǐng)求偽造(CSRF)攻擊中，惡意行為者會(huì)欺騙用戶通過(guò)瀏覽器無(wú)意中執(zhí)行惡意請(qǐng)求。例如，攻擊者可以在網(wǎng)站中嵌入精心設(shè)計(jì)的圖像源字符串，以觸發(fā)瀏覽器運(yùn)行GET請(qǐng)求，或者在惡意網(wǎng)站上添加表單，以觸發(fā)POST請(qǐng)求。在任何情況下，瀏覽器都可能會(huì)自動(dòng)將cookie(包括單點(diǎn)登錄cookie)添加到這樣的請(qǐng)求中。
CSRF攻擊也被稱(chēng)為“會(huì)話騎乘”，因?yàn)楣粽咄ǔ?huì)利用用戶的經(jīng)過(guò)身份驗(yàn)證的會(huì)話來(lái)進(jìn)行惡意請(qǐng)求。因此，攻擊者可以默默地代表用戶執(zhí)行請(qǐng)求，并調(diào)用用戶可以調(diào)用的任何端點(diǎn)。然而，攻擊者無(wú)法讀取響應(yīng)，所以他們通常以一次性狀態(tài)更改請(qǐng)求為目標(biāo)，如更新用戶的密碼。
跨站腳本(XSS)
跨站腳本(XSS)漏洞允許攻擊者將惡意的客戶端代碼注入到一個(gè)本來(lái)受信任的網(wǎng)站中。例如，如果用戶輸入生成的輸出沒(méi)有被適當(dāng)清理，web應(yīng)用程序的任何地方都可能存在漏洞。瀏覽器會(huì)自動(dòng)在受信任的網(wǎng)站的上下文中運(yùn)行惡意代碼。
XSS攻擊可用于竊取訪問(wèn)令牌和刷新令牌，或執(zhí)行CSRF攻擊。不過(guò)，XSS攻擊有一個(gè)時(shí)間窗口，因?yàn)樗鼈冎荒茉谟邢薜臅r(shí)間段內(nèi)運(yùn)行，如令牌的有效期內(nèi)，或者打開(kāi)的選項(xiàng)卡存在漏洞的時(shí)長(zhǎng)。
即使在XSS無(wú)法用于檢索訪問(wèn)令牌的情況下，攻擊者也可以利用XSS漏洞通過(guò)會(huì)話騎乘向有保護(hù)的Web端點(diǎn)發(fā)送經(jīng)過(guò)身份驗(yàn)證的請(qǐng)求。然后，攻擊者可以偽裝成用戶，調(diào)用用戶可以調(diào)用的任何后端端點(diǎn)，并造成嚴(yán)重?fù)p害。
瀏覽器中的存儲(chǔ)解決方案
應(yīng)用程序收到訪問(wèn)令牌后，需要存儲(chǔ)該令牌以在API請(qǐng)求中使用它。瀏覽器中有多種方法可以持久化數(shù)據(jù)。應(yīng)用程序可以使用專(zhuān)用API(如Web存儲(chǔ)API或IndexedDB)來(lái)存儲(chǔ)令牌。應(yīng)用程序也可以簡(jiǎn)單地將令牌保存在內(nèi)存中或?qū)⑵浞旁赾ookie中。一些存儲(chǔ)機(jī)制是持久的，另一些在一段時(shí)間后或頁(yè)面關(guān)閉或刷新后會(huì)被清除。
一些解決方案跨選項(xiàng)卡共享數(shù)據(jù)，而其他解決方案僅限于當(dāng)前選項(xiàng)卡。但是，本指南中介紹的大多數(shù)方法都針對(duì)每個(gè)源存儲(chǔ)數(shù)據(jù)。因此，對(duì)于任何相關(guān)討論來(lái)說(shuō)，理解一些概念很有幫助:origin和site。
某個(gè)(Web)資源的origin是其URL的scheme、hostname和port。例如，https://example.com/number/one和https://example.com:80/path/two具有相同的origin，因?yàn)樗鼈児蚕韘cheme(https)、hostname(example.com)和端口(默認(rèn)端口)。它們的origin為https://example.com，與https://example.com:8443或https://this.example.com不同，因?yàn)樗鼈冊(cè)诙丝诤椭鳈C(jī)名上有所不同。
相比之下，一個(gè)site比資源的origin要大。一個(gè)站點(diǎn)是為一組資源提供服務(wù)的Web應(yīng)用程序的通用名稱(chēng)。簡(jiǎn)單地說(shuō)，一個(gè)站點(diǎn)是scheme和domain name，如https://example.com。雖然https://example.com和https://this.example.com:8443有不同的origin(不同的主機(jī)名和端口)，但它們是相同的站點(diǎn)，因?yàn)樗鼈兺泄茉谕粋€(gè)域名(example.com)上并使用相同的scheme(https)。(從技術(shù)上講，這個(gè)定義還有細(xì)微差別，但這個(gè)簡(jiǎn)化的說(shuō)法有助于解釋這個(gè)概念)。
本地存儲(chǔ)
本地存儲(chǔ)是通過(guò)Web存儲(chǔ)API中的全局localStorage對(duì)象以JavaScript訪問(wèn)的。本地存儲(chǔ)中的數(shù)據(jù)在瀏覽器選項(xiàng)卡和會(huì)話之間可用，也就是說(shuō)它不會(huì)過(guò)期或在瀏覽器關(guān)閉時(shí)被刪除。因此，通過(guò)localStorage存儲(chǔ)的數(shù)據(jù)可以在應(yīng)用程序的所有選項(xiàng)卡中訪問(wèn)。因此，在本地存儲(chǔ)中存儲(chǔ)令牌非常誘人。
// Storing the access token
localStorage.setItem("token", accessToken);
// Loading the access token
let accessToken = localStorage.getItem("token");
每當(dāng)應(yīng)用程序調(diào)用API時(shí)，它都會(huì)從存儲(chǔ)中獲取令牌并手動(dòng)添加到請(qǐng)求中。但是，由于本地存儲(chǔ)可以通過(guò)JavaScript訪問(wèn)，這意味著該解決方案也容易受到跨站腳本(XSS)攻擊。
如果您在本地存儲(chǔ)中使用access token，并且攻擊者設(shè)法在您的應(yīng)用程序中運(yùn)行外部JavaScript代碼，那么攻擊者可以竊取任何令牌并直接調(diào)用API。此外，XSS還允許攻擊者操作應(yīng)用程序中的本地存儲(chǔ)數(shù)據(jù)，這意味著攻擊者可以更改令牌。
請(qǐng)注意，本地存儲(chǔ)中的數(shù)據(jù)會(huì)永久存儲(chǔ)，這意味著存儲(chǔ)在其中的任何令牌會(huì)駐留在用戶的設(shè)備(筆記本電腦、電腦、手機(jī)或其他設(shè)備)的文件系統(tǒng)上，即使瀏覽器關(guān)閉后也可以被其他應(yīng)用程序訪問(wèn)。因此，在使用localStorage時(shí)，請(qǐng)考慮終端安全性。考慮并防止瀏覽器之外的攻擊向量，如惡意軟件、被盜設(shè)備或磁盤(pán)。
根據(jù)上述討論，請(qǐng)遵循以下建議:
- 不要在本地存儲(chǔ)中存儲(chǔ)敏感數(shù)據(jù)，如令牌。
- 不要信任本地存儲(chǔ)中的數(shù)據(jù)(尤其是用于認(rèn)證和授權(quán)的數(shù)據(jù))。
會(huì)話存儲(chǔ)
會(huì)話存儲(chǔ)是Web存儲(chǔ)API提供的另一種存儲(chǔ)機(jī)制。與本地存儲(chǔ)不同，使用sessionStorage對(duì)象存儲(chǔ)的數(shù)據(jù)在選項(xiàng)卡或?yàn)g覽器關(guān)閉時(shí)會(huì)被清除。此外，session存儲(chǔ)中的數(shù)據(jù)在其他選項(xiàng)卡中不可訪問(wèn)。只有當(dāng)前選項(xiàng)卡和origin中的JavaScript代碼可以使用相同的會(huì)話存儲(chǔ)進(jìn)行讀取和寫(xiě)入。
// Storing the access token
sessionStorage.setItem("token", accessToken);
// Loading the access token
let accessToken = sessionStorage.getItem("token");
與本地存儲(chǔ)相比，會(huì)話存儲(chǔ)可以被認(rèn)為更安全，因?yàn)闉g覽器會(huì)在窗口關(guān)閉時(shí)自動(dòng)刪除任何令牌。此外，由于會(huì)話存儲(chǔ)不在選項(xiàng)卡之間共享，攻擊者無(wú)法從另一個(gè)選項(xiàng)卡(或窗口)讀取令牌，這減少了XSS攻擊的影響。
在實(shí)踐中，使用sessionStorage存儲(chǔ)令牌的主要安全問(wèn)題是XSS。如果您的應(yīng)用程序容易受到XSS攻擊，攻擊者可以從存儲(chǔ)中提取令牌并在API調(diào)用中重放它。因此，會(huì)話存儲(chǔ)不適合存儲(chǔ)敏感數(shù)據(jù)，如令牌。
IndexedDB
IndexedDB是索引數(shù)據(jù)庫(kù)API的縮寫(xiě)。它是一個(gè)用于在瀏覽器中異步存儲(chǔ)大量數(shù)據(jù)的API。但是，在存儲(chǔ)令牌時(shí)，這個(gè)瀏覽器API提供的功能和容量通常不是必需的。由于應(yīng)用程序在每次API調(diào)用中都發(fā)送令牌，最好是使令牌的大小最小化。
與迄今為止討論的其他客戶端存儲(chǔ)機(jī)制一樣，使用索引數(shù)據(jù)庫(kù)API存儲(chǔ)的數(shù)據(jù)訪問(wèn)受到同源策略的限制。只有相同來(lái)源的資源和服務(wù)工作者才能訪問(wèn)數(shù)據(jù)。從安全角度來(lái)看，IndexedDB與本地存儲(chǔ)相當(dāng):
- 令牌可能會(huì)通過(guò)文件系統(tǒng)泄露。
- 令牌可能會(huì)通過(guò)XSS攻擊泄露。
因此，不要在IndexedDB中存儲(chǔ)訪問(wèn)令牌或其他敏感數(shù)據(jù)。IndexedDB更適合用于應(yīng)用程序脫機(jī)工作所需的數(shù)據(jù)，如圖像。
內(nèi)存
存儲(chǔ)令牌的一個(gè)相當(dāng)安全的方法是將其保存在內(nèi)存中。與其他方法相比，令牌不存儲(chǔ)在文件系統(tǒng)中，從而減輕了與設(shè)備文件系統(tǒng)相關(guān)的風(fēng)險(xiǎn)。
最佳實(shí)踐建議在內(nèi)存中存儲(chǔ)令牌時(shí)將其保存在閉包中。例如，您可以定義一個(gè)單獨(dú)的方法來(lái)使用令牌調(diào)用API。它不會(huì)向主應(yīng)用程序(主線程)透露令牌。下面的摘錄顯示了如何在JavaScript中使用內(nèi)存處理令牌的示例。
function protectedCalls(tokenResponse) {
const accessToken = tokenResponse.accessToken;
return {
// call API with access token
getOrders: () => {
const req = new Request("https://server.example/orders");
req.headers.set("Authorization", accessToken);
return fetch(req)
}
}
}
const apiClient = protectedCalls(tokenResponse);
// call protected API
apiClient.getOrders();
請(qǐng)注意，攻擊者可能無(wú)法在獲取令牌后直接訪問(wèn)令牌，因此可能無(wú)法直接使用令牌調(diào)用API。即便如此，通過(guò)持有令牌引用的apiClient，他們可以隨時(shí)通過(guò)apiClient調(diào)用API。但是，任何此類(lèi)攻擊都限于選項(xiàng)卡打開(kāi)并且接口提供的功能的時(shí)段。
除了與潛在的XSS漏洞相關(guān)的安全問(wèn)題外，在內(nèi)存中保持令牌的最大缺點(diǎn)是頁(yè)面重載時(shí)令牌會(huì)丟失。然后，應(yīng)用程序必須獲取一個(gè)新令牌，這可能會(huì)觸發(fā)新的用戶身份驗(yàn)證。安全的設(shè)計(jì)應(yīng)考慮到用戶體驗(yàn)。
使用服務(wù)工作者的體系結(jié)構(gòu)通過(guò)在獨(dú)立的線程中運(yùn)行令牌處理功能來(lái)減輕可用性問(wèn)題，該線程與主網(wǎng)頁(yè)分離。服務(wù)工作者實(shí)際上充當(dāng)應(yīng)用程序、瀏覽器和網(wǎng)絡(luò)之間的代理。因此，它們可以攔截請(qǐng)求和響應(yīng)，例如緩存數(shù)據(jù)和啟用離線訪問(wèn)，或者獲取和添加令牌。
在使用JavaScript閉包或服務(wù)工作者處理令牌和API請(qǐng)求時(shí)，XSS攻擊可能會(huì)針對(duì)OAuth流程，如回調(diào)流或靜默流來(lái)獲取令牌。它們可以取消注冊(cè)并繞過(guò)任何服務(wù)工作者，或者使用原型污染“實(shí)時(shí)讀取令牌”通過(guò)覆蓋諸如window.fetch之類(lèi)的方法。因此，請(qǐng)出于方便而不是安全性考慮JavaScript閉包和服務(wù)工作者。
Cookie
Cookie是存儲(chǔ)在瀏覽器中的數(shù)據(jù)片段。由設(shè)計(jì)，瀏覽器會(huì)將cookie添加到對(duì)服務(wù)器的每個(gè)請(qǐng)求中。因此，應(yīng)用程序必須謹(jǐn)慎使用cookie。如果未經(jīng)仔細(xì)配置，瀏覽器可能會(huì)在跨站請(qǐng)求時(shí)追加cookie，并允許跨站請(qǐng)求偽造(CSRF)攻擊。
Cookie具有控制其安全屬性的屬性。例如，SameSite屬性可以幫助緩解CSRF攻擊的風(fēng)險(xiǎn)。當(dāng)一個(gè)cookie的SameSite屬性設(shè)置為Strict時(shí)，瀏覽器只會(huì)將其添加到源自并目標(biāo)與cookie的源站點(diǎn)相同的請(qǐng)求中。當(dāng)請(qǐng)求嵌入在任何第三方網(wǎng)站中時(shí)，瀏覽器不會(huì)添加cookie，例如通過(guò)鏈接。
您可以通過(guò)JavaScript設(shè)置和檢索cookie。但是，當(dāng)使用JavaScript讀取cookie時(shí)，應(yīng)用程序會(huì)變得容易受到XSS攻擊(除了CSRF之外)。因此，首選的選擇是讓后端組件設(shè)置cookie并將其標(biāo)記為HttpOnly。該標(biāo)志可以緩解通過(guò)XSS攻擊泄露數(shù)據(jù)的問(wèn)題，因?yàn)樗甘緸g覽器cookie不能通過(guò)JavaScript訪問(wèn)。
為防止cookie通過(guò)中間人攻擊泄露，這可能導(dǎo)致會(huì)話劫持，cookie應(yīng)僅通過(guò)加密連接(HTTPS)發(fā)送。要指示瀏覽器僅在HTTPS請(qǐng)求中發(fā)送cookie，必須將Secure屬性設(shè)置為cookie。
Set-Cookie:token=myvalue;SameSite=Strict;Secure;HttpOnly
與瀏覽器中的任何其他永久存儲(chǔ)解決方案一樣，cookie可能會(huì)駐留在文件系統(tǒng)中，即使瀏覽器已關(guān)閉(例如，cookie不必過(guò)期，或者瀏覽器可以將會(huì)話cookie作為恢復(fù)會(huì)話功能的一部分保留)。為了減輕從文件系統(tǒng)中竊取令牌的風(fēng)險(xiǎn)，只能在cookie中存儲(chǔ)加密的令牌。因此，后端組件只能在Set-Cookie頭中返回加密的令牌。
威脅矩陣
下表總結(jié)了瀏覽器中存儲(chǔ)解決方案的威脅評(píng)估，主要威脅向量標(biāo)記為紅色。橙色威脅需要除Web技術(shù)之外的緩解措施。綠色威脅已經(jīng)或可以通過(guò)適當(dāng)?shù)脑O(shè)置成功消除。
無(wú)論攻擊者何時(shí)設(shè)法竊取令牌，只要令牌有效，他們就可以獨(dú)立于用戶和應(yīng)用程序使用訪問(wèn)令牌。如果攻擊者設(shè)法竊取刷新令牌，他們可以顯著延長(zhǎng)攻擊時(shí)間并增加損害，因?yàn)樗麄兛梢岳m(xù)新訪問(wèn)令牌。黑客甚至可以將攻擊擴(kuò)展到除JavaScript應(yīng)用程序使用的API之外的其他API。例如，攻擊者可以嘗試重放訪問(wèn)令牌并利用不同API中的漏洞。
被盜的訪問(wèn)令牌可能會(huì)造成嚴(yán)重?fù)p害，XSS仍然是Web應(yīng)用程序的主要問(wèn)題。因此，避免在客戶端代碼可以訪問(wèn)的地方存儲(chǔ)訪問(wèn)令牌。相反，將訪問(wèn)令牌存儲(chǔ)在cookie中。當(dāng)使用適當(dāng)?shù)膶傩耘渲胏ookie時(shí)，瀏覽器泄露訪問(wèn)令牌的風(fēng)險(xiǎn)為零。然后，XSS攻擊與在同一站點(diǎn)上的會(huì)話劫持攻擊相當(dāng)。
使用Cookie的OAuth語(yǔ)義
Cookie仍然是傳輸令牌和充當(dāng)API憑據(jù)的最佳選擇，因?yàn)榧词构粽叱晒肵SS漏洞，也無(wú)法從cookie中檢索訪問(wèn)令牌。但是，為了做到這一點(diǎn)，cookie必須適當(dāng)配置。
首先，將cookie標(biāo)記為HttpOnly，以便它們不可通過(guò)JavaScript訪問(wèn)，以解決XSS攻擊的風(fēng)險(xiǎn)。另一個(gè)關(guān)鍵屬性是Secure標(biāo)志，它確保cookie僅通過(guò)HTTPS發(fā)送，以減輕中間人攻擊。
其次，頒發(fā)短暫的只在幾分鐘內(nèi)有效的訪問(wèn)令牌。在最壞的情況下，具有最小有效期的訪問(wèn)令牌只能在可以接受的短時(shí)間內(nèi)被濫用。通常認(rèn)為15分鐘的有效期是合適的。讓cookie和令牌的過(guò)期時(shí)間大致相同。
第三，將令牌視為敏感數(shù)據(jù)。只在cookie中存儲(chǔ)加密令牌。如果攻擊者設(shè)法獲取加密令牌，他們將無(wú)法從中解析任何數(shù)據(jù)。攻擊者也無(wú)法將加密的令牌重放到任何其他API，因?yàn)槠渌鸄PI無(wú)法解密令牌。加密令牌只是限制了被盜令牌的影響。
第四，在發(fā)送API憑據(jù)時(shí)要限制性強(qiáng)。只向需要API憑據(jù)的資源發(fā)送cookie。這意味著確保瀏覽器只在實(shí)際需要訪問(wèn)令牌的API調(diào)用中添加cookie。為此，cookie需要有適當(dāng)?shù)脑O(shè)置，比如SameSite=Strict、指向API端點(diǎn)域的域?qū)傩院吐窂健?/p>
最后，在使用刷新令牌時(shí)，請(qǐng)確保將它們存儲(chǔ)在自己的cookie中。沒(méi)有必要在每個(gè)API請(qǐng)求中都發(fā)送它們，所以請(qǐng)確保不是這種情況。刷新令牌必須只在刷新過(guò)期的訪問(wèn)令牌時(shí)添加。這意味著包含刷新令牌的cookie與包含訪問(wèn)令牌的cookie有稍微不同的設(shè)置。
令牌處理程序模式
在JavaScript客戶端中為OAuth提供最佳實(shí)踐原則的設(shè)計(jì)模式是令牌處理程序模式。它遵循OAuth 2.0 for Browser-Based Apps中描述的BFF(backend for frontend)方法。該模式引入了一個(gè)后端組件，能夠發(fā)出帶有加密令牌和上述必要屬性的cookie。
后端組件的責(zé)任是:
- 作為OAuth客戶端與授權(quán)服務(wù)器交互，啟動(dòng)用戶認(rèn)證并獲取令牌。
- 管理JavaScript應(yīng)用程序的令牌，使其不可訪問(wèn)。
- 代理和攔截所有API請(qǐng)求，以附加正確的訪問(wèn)令牌。
令牌處理程序模式定義了一個(gè)BFF，它為在瀏覽器中運(yùn)行的應(yīng)用程序抽象了OAuth。換句話說(shuō)，令牌處理程序模式建議一個(gè)JavaScript應(yīng)用程序可以用來(lái)認(rèn)證用戶并安全地調(diào)用API的API。為此，該模式使用cookie來(lái)存儲(chǔ)和發(fā)送訪問(wèn)令牌。
令牌處理程序是一個(gè)后端組件，例如可以駐留在API網(wǎng)關(guān)中。它由兩部分組成:
- OAuth代理，它處理OAuth流以從授權(quán)服務(wù)器獲取令牌。
- OAuth代理，它攔截對(duì)API的所有請(qǐng)求并將cookie轉(zhuǎn)換為令牌。
OAuth代理獲取令牌后，它會(huì)發(fā)出帶有以下屬性的cookie:
- SameSite=Strict
- HttpOnly
- Secure
- API的路徑
由于令牌處理程序是一個(gè)后端組件，所以O(shè)Auth代理是一個(gè)保密的客戶端，可以向授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證(與公開(kāi)的JavaScript客戶端相比)。這意味著為了獲得令牌，OAuth代理需要進(jìn)行身份驗(yàn)證。因此，攻擊者需要獲取客戶端憑據(jù)才能成功獲取新令牌。在JavaScript中運(yùn)行靜默流而沒(méi)有客戶端憑據(jù)將失敗。
為了令牌處理程序模式能夠工作，JavaScript應(yīng)用程序和令牌處理程序組件必須部署在同一站點(diǎn)上(換句話說(shuō)，它們必須在同一域中運(yùn)行)。否則，由于cookie上的同站限制，瀏覽器不會(huì)將令牌cookie添加到API請(qǐng)求中。
要獲取數(shù)據(jù)，JavaScript應(yīng)用程序只需通過(guò)OAuth代理調(diào)用API:
// http://www.example.com/app.js
// Call to OAuth Proxy
const response = await fetch("https://api.example.com/orders", {
// Instruct the browser to add cookies to cross-origin requests
credentials: "include"
});
瀏覽器會(huì)自動(dòng)將cookie添加到請(qǐng)求中。在上面的示例中，瀏覽器將cookie包含在跨域請(qǐng)求中。但是，由于cookie屬性SameSite=Strict，瀏覽器只會(huì)將cookie添加到同一站點(diǎn)(同一域)的跨域請(qǐng)求中。
OAuth代理解密cookie并將令牌添加到上游API。cookie屬性確保瀏覽器僅將cookie添加到HTTPS請(qǐng)求中，以確保它們?cè)趥鬏斶^(guò)程中是安全的。由于令牌是加密的，它們?cè)谛菹r(shí)也是安全的。然后令牌用于安全訪問(wèn)API。
總結(jié)
使用OAuth和訪問(wèn)令牌可以最好地保護(hù)API訪問(wèn)。但是，JavaScript應(yīng)用程序處于不利地位。瀏覽器中沒(méi)有安全的令牌存儲(chǔ)解決方案。所有可用的解決方案在某種程度上都容易受到XSS攻擊。因此，確保任何應(yīng)用程序安全的首要任務(wù)應(yīng)該是防止XSS漏洞。
令牌處理程序模式通過(guò)在JavaScript無(wú)法訪問(wèn)的cookie中存儲(chǔ)加密令牌來(lái)緩解XSS風(fēng)險(xiǎn)。它將Web關(guān)注點(diǎn)與API關(guān)注點(diǎn)分離，并提供指導(dǎo)，使用成熟的Web技術(shù)加固JavaScript應(yīng)用程序，而不會(huì)破壞Web架構(gòu)。查看令牌處理程序模式的詳細(xì)描述，并探索各種示例。
