如何存儲這些令牌。如果你正在構建一個web應用程序，你有兩種選擇:
- HTML5 Web Storage (localStorage或sessionStorage)
- Cookies
比較這兩個，假設我們有一個虛構的AngularJS或單頁應用(SPA)叫做galaxies.com，登錄路由(/token)驗證用戶身份返回一個JWT。訪問你的SPA其他API端點服務，客戶端需要傳遞一個有效的JWT。
單一頁面應用程序的請求將會類似:
HTTP/1.1
POST /token
Host: galaxies.com
Content-Type: application/x-www-form-urlencoded
username=tom@galaxies.com&password=andromedaisheadingstraightforusomg&grant_type=password
你的服務器的響應會根據你是否使用cookie或Web Storage而變化。為了比較，讓我們看看如何兩者兼顧。
JWT localStorage或sessionStorage(Web存儲)
用username和password交換JWT存儲在瀏覽器存儲中(sessionStorage或localStorage)是相當簡單的。響應正文將包含JWT作為一個訪問令牌:
HTTP/1.1 200 OK
{
"access_token": "eyJhbGciOiJIUzI1NiIsI.eyJpc3MiOiJodHRwczotcGxlL.mFrs3Zo8eaSNcxiNfvRh9dqKP4F1cB",
"expires_in":3600
}
在客戶端，你可以將這個令牌存儲在HTML5 Web存儲中(假設我們有一個成功的回調函數)：
function tokenSuccess(err, response) {
if(err){
throw err;
}
$window.sessionStorage.accessToken = response.body.access_token;
}
回傳訪問令牌到你受保護的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中也很簡單。響應使用Set-Cookie HTTP頭:
HTTP/1.1 200 OK
Set-Cookie: access_token=eyJhbGciOiJIUzI1NiIsI.eyJpc3MiOiJodHRwczotcGxlL.mFrs3Zo8eaSNcxiNfvRh9dqKP4F1cB; Secure; HttpOnly;
回傳訪問令牌到你同一領域受保護的API，瀏覽器將自動包括cookie的值。請求你受保護的API將類似于:
GET /stars/pollux
Host: galaxies.com
Cookie: access_token=eyJhbGciOiJIUzI1NiIsI.eyJpc3MiOiJodHRwczotcGxlL.mFrs3Zo8eaSNcxiNfvRh9dqKP4F1cB;
那么，有什么區別呢？
如果你比較這些方法，兩者都獲取一個JWT到瀏覽器。兩者都是無狀態的，因為你的API需要的所有信息都在JWT中。都是簡單的傳遞備份到你受保護的API。區別在于介質。
JWT sessionStorage和localStorage的安全性
Web存儲(localStorage/sessionStorage)可以通過同一域上JavaScript訪問。這意味著任何在你的網站上運行的JavaScript都可以訪問Web存儲，因為這樣容易受到跨站點腳本（XSS）攻擊。XSS，簡而言之，是一種漏洞，攻擊者可以注入在頁面上運行的JavaScript。基本的XSS攻擊試圖通過input表單注入JavaScript,攻擊者將<script>alert('You are Hacked');</script>放入表單，以查看其是否能被瀏覽器運行，并能被其他用戶查看。
為了防止XSS，普通的響應是避開和編碼所有不可信的數據。但這遠不是故事的全部。2015年，現代的web應用程序使用托管在CDN或者外部基礎設施上的JavaScript。現代的Web應用程序使用第三方JavaScript庫，用于A/B測試、 funnel/market analysis和廣告。我們使用像Bower這樣的包管理器導入別人的代碼到我們的應用程序。
如果你使用的腳本中有一個被盜用了怎么辦?惡意的JavaScript可以嵌入到頁面上，并且Web存儲被盜用。這些類型的XSS攻擊可以得到每個人的Web存儲來訪問你的網站，沒有他們的知識。這可能是為什么許多組織建議不要在Web存儲中存儲任何有價值或信任任何Web存儲中的信息。這包括會話標識符和令牌。
作為一種存儲機制，Web存儲在傳輸過程中不強制執行任何安全標準。無論誰讀取和使用Web存儲，必須進行盡職調查以確保他們總是通過HTTPS發送JWT，絕不用HTTP。
JWT Cookie存儲的安全性
Cookies，當使用帶有HttpOnly的cookie標志時，通過JavaScript是無法訪問的，并且對XSS是免疫的。你還可以設置安全的cookie標志來保證cokie僅通過HTTPS發送。這是過去利用cookie存儲令牌或會話數據的主要原因之一。現代開發人員不愿使用cookie,因為它們通常要求狀態被存儲在服務器上,從而打破RESTful的最佳實踐。如果你在cookie上存儲JWT，cookie作為存儲機制不用將狀態存儲在服務器上。這是因為JWT封裝了所有服務器需要服務的請求。
然而，cookies容易受到不同類型的攻擊：跨站點請求偽造(CSRF)。CSRF攻擊是當一個惡意網站，電子郵件或博客導致用戶在當前已驗證用戶的可信站點上的web瀏覽器中，執行一個有害的動作時發生的攻擊。這是一個瀏覽器如何處理cookies的漏洞。cookie只能被發送到的允許的域中。默認情況下，這個是最初設置cookie的域。請求將發送一個cookie無論你在galaxies.com或hahagonnahackyou.com。
CSRF的工作試圖引誘你到hahagonnahackyou.com。該網站將有一個img標記或JavaScript來模擬一個表單post到galaxies.com，并試圖劫持你的會話，如果它仍然有效，就修改您的帳戶。
例如：
<body>
<!– CSRF 用img標簽 –>
<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>
兩者都將發送cookie為galaxies.com，并可能導致未經授權的狀態改變。使用同步令牌模式，CSRF是可以預防的。這聽起來很復雜，但是所有現代的web框架都支持這個。
例如，AngularJS有一個解決方案去驗證，只能由你的域才能訪問cookie。直接來自AngularJS文檔:
當執行XHR請求時，$http服務從cookie中讀取令牌(默認，XSRF-TOKEN)并將其作為一個http頭(X-XSRF-TOKEN)。因為只有JavaScript運行在你的域才可以讀取cookie,你的服務器可以確信XHR來
自你的域中運行的JavaScript。通過包含一個xsrfToken JWT claim，你可以讓這個CSRF保護無狀態。
{
"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，獲得無狀態CSRF保護沒有開發工作。
利用你的web應用程序框架的CSRF保護，使得cookies存儲JWT絕對可靠。CSRF也可以從你的API中通過檢查HTTP Referer和原始header部分阻止。CSRF攻擊將有與應用程序無關的Referer和原始heade。
雖然他們更安全的存儲你的JWT，cookies可能導致一些開發商頭痛，這取決于你的應用程序的運轉是否需要跨域訪問。只是知道cookies有附加屬性(域名/路徑)，可以對其進行修改，從而允許你指定cookie的發送位置。使用AJAX，你的服務器端也可以通知瀏覽器證書(包含Cookies)是否應該隨著CORS請求發送。
結論
JWTs是一個很棒的身份驗證機制。它們給你一個結構化的方式聲明用戶和它們可以訪問的內容。可以對它們進行加密和簽名來防止在客戶端進行篡改，但魔鬼在于細節和你把它們存放在哪里。
Stormpath建議你把JWT存儲到Web應用程序的cookies中，因為他們提供的額外的安全性，防止現代web框架CSRF的簡單性。HTML5 Web存儲很容易受到XSS攻擊，有一個更大的攻擊面積，一個成功的攻擊會影響所有應用程序的用戶。
