你的JWTs存儲在哪里

如何存儲這些令牌。如果你正在構(gòu)建一個web應(yīng)用程序，你有兩種選擇:

  • HTML5 Web Storage (localStorage或sessionStorage)
  • Cookies

比較這兩個，假設(shè)我們有一個虛構(gòu)的AngularJS或單頁應(yīng)用(SPA)叫做galaxies.com，登錄路由(/token)驗(yàn)證用戶身份返回一個JWT。訪問你的SPA其他API端點(diǎn)服務(wù)，客戶端需要傳遞一個有效的JWT。

單一頁面應(yīng)用程序的請求將會類似:

HTTP/1.1
 
POST /token
Host: galaxies.com
Content-Type: application/x-www-form-urlencoded
 
username=tom@galaxies.com&password=andromedaisheadingstraightforusomg&grant_type=password

你的服務(wù)器的響應(yīng)會根據(jù)你是否使用cookie或Web Storage而變化。為了比較，讓我們看看如何兩者兼顧。

JWT localStorage或sessionStorage(Web存儲)

用username和password交換JWT存儲在瀏覽器存儲中(sessionStorage或localStorage)是相當(dāng)簡單的。響應(yīng)正文將包含JWT作為一個訪問令牌:

HTTP/1.1 200 OK
 
  {
  "access_token": "eyJhbGciOiJIUzI1NiIsI.eyJpc3MiOiJodHRwczotcGxlL.mFrs3Zo8eaSNcxiNfvRh9dqKP4F1cB",
       "expires_in":3600
   }

在客戶端，你可以將這個令牌存儲在HTML5 Web存儲中(假設(shè)我們有一個成功的回調(diào)函數(shù))：

function tokenSuccess(err, response) {
    if(err){
        throw err;
    }
    $window.sessionStorage.accessToken = response.body.access_token;
}

回傳訪問令牌到你受保護(hù)的API，你將使用HTTP Authorization Header和Bearer組合。請求你的SPA將會像:

HTTP/1.1
 
GET /stars/pollux
Host: galaxies.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsI.eyJpc3MiOiJodHRwczotcGxlL.mFrs3Zo8eaSNcxiNfvRh9dqKP4F1cB

JWT Cookie Storage

用username和password交換JWT存儲在cookie中也很簡單。響應(yīng)使用Set-Cookie HTTP頭:

HTTP/1.1 200 OK
 
Set-Cookie: access_token=eyJhbGciOiJIUzI1NiIsI.eyJpc3MiOiJodHRwczotcGxlL.mFrs3Zo8eaSNcxiNfvRh9dqKP4F1cB; Secure; HttpOnly;

回傳訪問令牌到你同一領(lǐng)域受保護(hù)的API，瀏覽器將自動包括cookie的值。請求你受保護(hù)的API將類似于:

GET /stars/pollux
Host: galaxies.com
 
Cookie: access_token=eyJhbGciOiJIUzI1NiIsI.eyJpc3MiOiJodHRwczotcGxlL.mFrs3Zo8eaSNcxiNfvRh9dqKP4F1cB;

那么，有什么區(qū)別呢？

如果你比較這些方法，兩者都獲取一個JWT到瀏覽器。兩者都是無狀態(tài)的，因?yàn)槟愕腁PI需要的所有信息都在JWT中。都是簡單的傳遞備份到你受保護(hù)的API。區(qū)別在于介質(zhì)。

JWT sessionStorage和localStorage的安全性

Web存儲(localStorage/sessionStorage)可以通過同一域上JavaScript訪問。這意味著任何在你的網(wǎng)站上運(yùn)行的JavaScript都可以訪問Web存儲，因?yàn)檫@樣容易受到跨站點(diǎn)腳本（XSS）攻擊。XSS，簡而言之，是一種漏洞，攻擊者可以注入在頁面上運(yùn)行的JavaScript?；镜腦SS攻擊試圖通過input表單注入JavaScript,攻擊者將<script>alert('You are Hacked');</script>放入表單，以查看其是否能被瀏覽器運(yùn)行，并能被其他用戶查看。

為了防止XSS，普通的響應(yīng)是避開和編碼所有不可信的數(shù)據(jù)。但這遠(yuǎn)不是故事的全部。2015年，現(xiàn)代的web應(yīng)用程序使用托管在CDN或者外部基礎(chǔ)設(shè)施上的JavaScript?，F(xiàn)代的Web應(yīng)用程序使用第三方JavaScript庫，用于A/B測試、 funnel/market analysis和廣告。我們使用像Bower這樣的包管理器導(dǎo)入別人的代碼到我們的應(yīng)用程序。

如果你使用的腳本中有一個被盜用了怎么辦?惡意的JavaScript可以嵌入到頁面上，并且Web存儲被盜用。這些類型的XSS攻擊可以得到每個人的Web存儲來訪問你的網(wǎng)站，沒有他們的知識。這可能是為什么許多組織建議不要在Web存儲中存儲任何有價值或信任任何Web存儲中的信息。這包括會話標(biāo)識符和令牌。

作為一種存儲機(jī)制，Web存儲在傳輸過程中不強(qiáng)制執(zhí)行任何安全標(biāo)準(zhǔn)。無論誰讀取和使用Web存儲，必須進(jìn)行盡職調(diào)查以確保他們總是通過HTTPS發(fā)送JWT，絕不用HTTP。

JWT Cookie存儲的安全性

Cookies，當(dāng)使用帶有HttpOnly的cookie標(biāo)志時，通過JavaScript是無法訪問的，并且對XSS是免疫的。你還可以設(shè)置安全的cookie標(biāo)志來保證cokie僅通過HTTPS發(fā)送。這是過去利用cookie存儲令牌或會話數(shù)據(jù)的主要原因之一?，F(xiàn)代開發(fā)人員不愿使用cookie,因?yàn)樗鼈兺ǔＲ鬆顟B(tài)被存儲在服務(wù)器上,從而打破RESTful的最佳實(shí)踐。如果你在cookie上存儲JWT，cookie作為存儲機(jī)制不用將狀態(tài)存儲在服務(wù)器上。這是因?yàn)镴WT封裝了所有服務(wù)器需要服務(wù)的請求。

然而，cookies容易受到不同類型的攻擊：跨站點(diǎn)請求偽造(CSRF)。CSRF攻擊是當(dāng)一個惡意網(wǎng)站，電子郵件或博客導(dǎo)致用戶在當(dāng)前已驗(yàn)證用戶的可信站點(diǎn)上的web瀏覽器中，執(zhí)行一個有害的動作時發(fā)生的攻擊。這是一個瀏覽器如何處理cookies的漏洞。cookie只能被發(fā)送到的允許的域中。默認(rèn)情況下，這個是最初設(shè)置cookie的域。請求將發(fā)送一個cookie無論你在galaxies.com或hahagonnahackyou.com。

CSRF的工作試圖引誘你到hahagonnahackyou.com。該網(wǎng)站將有一個img標(biāo)記或JavaScript來模擬一個表單post到galaxies.com，并試圖劫持你的會話，如果它仍然有效，就修改您的帳戶。

例如：

<body>
 
  <!– CSRF 用img標(biāo)簽 –>
 
  <img  />
 
  <!– 或用一個隱藏表單post–>
 
  <script type="text/javascript">
  $(document).ready(function() {
    window.document.forms[0].submit();
  });
  </script>
 
  <div style="display:none;">
    <form action="http://galaxies.com/stars/pollux" method="POST">
      <input name="transferTo" value="tom@stealingstars.com" />
    <form>
  </div>
</body>

兩者都將發(fā)送cookie為galaxies.com，并可能導(dǎo)致未經(jīng)授權(quán)的狀態(tài)改變。使用同步令牌模式，CSRF是可以預(yù)防的。這聽起來很復(fù)雜，但是所有現(xiàn)代的web框架都支持這個。

例如，AngularJS有一個解決方案去驗(yàn)證，只能由你的域才能訪問cookie。直接來自AngularJS文檔:

當(dāng)執(zhí)行XHR請求時，$http服務(wù)從cookie中讀取令牌(默認(rèn)，XSRF-TOKEN)并將其作為一個http頭(X-XSRF-TOKEN)。因?yàn)橹挥蠮avaScript運(yùn)行在你的域才可以讀取cookie,你的服務(wù)器可以確信XHR來

自你的域中運(yùn)行的JavaScript。通過包含一個xsrfToken JWT claim，你可以讓這個CSRF保護(hù)無狀態(tài)。

{
  "iss": "http://galaxies.com",
  "exp": 1300819380,
  "scopes": ["explorer", "solar-harvester", "seller"],
  "sub": "tom@andromeda.com",
  "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"
}

如果我使用Stormpath SDK for AngularJS，獲得無狀態(tài)CSRF保護(hù)沒有開發(fā)工作。

利用你的web應(yīng)用程序框架的CSRF保護(hù)，使得cookies存儲JWT絕對可靠。CSRF也可以從你的API中通過檢查HTTP Referer和原始header部分阻止。CSRF攻擊將有與應(yīng)用程序無關(guān)的Referer和原始heade。

雖然他們更安全的存儲你的JWT，cookies可能導(dǎo)致一些開發(fā)商頭痛，這取決于你的應(yīng)用程序的運(yùn)轉(zhuǎn)是否需要跨域訪問。只是知道cookies有附加屬性(域名/路徑)，可以對其進(jìn)行修改，從而允許你指定cookie的發(fā)送位置。使用AJAX，你的服務(wù)器端也可以通知瀏覽器證書(包含Cookies)是否應(yīng)該隨著CORS請求發(fā)送。

結(jié)論

JWTs是一個很棒的身份驗(yàn)證機(jī)制。它們給你一個結(jié)構(gòu)化的方式聲明用戶和它們可以訪問的內(nèi)容。可以對它們進(jìn)行加密和簽名來防止在客戶端進(jìn)行篡改，但魔鬼在于細(xì)節(jié)和你把它們存放在哪里。
Stormpath建議你把JWT存儲到Web應(yīng)用程序的cookies中，因?yàn)樗麄兲峁┑念~外的安全性，防止現(xiàn)代web框架CSRF的簡單性。HTML5 Web存儲很容易受到XSS攻擊，有一個更大的攻擊面積，一個成功的攻擊會影響所有應(yīng)用程序的用戶。

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容