如何存儲這些令牌插勤。如果你正在構(gòu)建一個web應(yīng)用程序，你有兩種選擇:
- HTML5 Web Storage (localStorage或sessionStorage)
- Cookies
比較這兩個，假設(shè)我們有一個虛構(gòu)的AngularJS或單頁應(yīng)用(SPA)叫做galaxies.com辕棚，登錄路由(/token)驗證用戶身份返回一個JWT逆粹。訪問你的SPA其他API端點服務(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)是相當簡單的默刚。響應(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;
}
回傳訪問令牌到你受保護的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)域受保護的API伍俘，瀏覽器將自動包括cookie的值邪锌。請求你受保護的API將類似于:
GET /stars/pollux
Host: galaxies.com
Cookie: access_token=eyJhbGciOiJIUzI1NiIsI.eyJpc3MiOiJodHRwczotcGxlL.mFrs3Zo8eaSNcxiNfvRh9dqKP4F1cB;
那么，有什么區(qū)別呢癌瘾？
如果你比較這些方法觅丰，兩者都獲取一個JWT到瀏覽器。兩者都是無狀態(tài)的妨退，因為你的API需要的所有信息都在JWT中妇萄。都是簡單的傳遞備份到你受保護的API。區(qū)別在于介質(zhì)碧注。
JWT sessionStorage和localStorage的安全性
Web存儲(localStorage/sessionStorage)可以通過同一域上JavaScript訪問嚣伐。這意味著任何在你的網(wǎng)站上運行的JavaScript都可以訪問Web存儲，因為這樣容易受到跨站點腳本（XSS）攻擊萍丐。XSS轩端，簡而言之，是一種漏洞逝变，攻擊者可以注入在頁面上運行的JavaScript基茵》芄梗基本的XSS攻擊試圖通過input表單注入JavaScript,攻擊者將<script>alert('You are Hacked');</script>放入表單，以查看其是否能被瀏覽器運行拱层，并能被其他用戶查看弥臼。
為了防止XSS，普通的響應(yīng)是避開和編碼所有不可信的數(shù)據(jù)根灯。但這遠不是故事的全部径缅。2015年，現(xiàn)代的web應(yīng)用程序使用托管在CDN或者外部基礎(chǔ)設(shè)施上的JavaScript±臃危現(xiàn)代的Web應(yīng)用程序使用第三方JavaScript庫纳猪，用于A/B測試、 funnel/market analysis和廣告桃笙。我們使用像Bower這樣的包管理器導(dǎo)入別人的代碼到我們的應(yīng)用程序氏堤。
如果你使用的腳本中有一個被盜用了怎么辦?惡意的JavaScript可以嵌入到頁面上，并且Web存儲被盜用搏明。這些類型的XSS攻擊可以得到每個人的Web存儲來訪問你的網(wǎng)站鼠锈，沒有他們的知識。這可能是為什么許多組織建議不要在Web存儲中存儲任何有價值或信任任何Web存儲中的信息星著。這包括會話標識符和令牌购笆。
作為一種存儲機制，Web存儲在傳輸過程中不強制執(zhí)行任何安全標準强饮。無論誰讀取和使用Web存儲由桌，必須進行盡職調(diào)查以確保他們總是通過HTTPS發(fā)送JWT为黎，絕不用HTTP邮丰。
JWT Cookie存儲的安全性
Cookies，當使用帶有HttpOnly的cookie標志時铭乾，通過JavaScript是無法訪問的剪廉，并且對XSS是免疫的。你還可以設(shè)置安全的cookie標志來保證cokie僅通過HTTPS發(fā)送炕檩。這是過去利用cookie存儲令牌或會話數(shù)據(jù)的主要原因之一《方現(xiàn)代開發(fā)人員不愿使用cookie,因為它們通常要求狀態(tài)被存儲在服務(wù)器上,從而打破RESTful的最佳實踐。如果你在cookie上存儲JWT笛质，cookie作為存儲機制不用將狀態(tài)存儲在服務(wù)器上泉沾。這是因為JWT封裝了所有服務(wù)器需要服務(wù)的請求。
然而妇押，cookies容易受到不同類型的攻擊：跨站點請求偽造(CSRF)跷究。CSRF攻擊是當一個惡意網(wǎng)站，電子郵件或博客導(dǎo)致用戶在當前已驗證用戶的可信站點上的web瀏覽器中敲霍，執(zhí)行一個有害的動作時發(fā)生的攻擊俊马。這是一個瀏覽器如何處理cookies的漏洞丁存。cookie只能被發(fā)送到的允許的域中。默認情況下柴我，這個是最初設(shè)置cookie的域解寝。請求將發(fā)送一個cookie無論你在galaxies.com或hahagonnahackyou.com。
CSRF的工作試圖引誘你到hahagonnahackyou.com艘儒。該網(wǎng)站將有一個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>
兩者都將發(fā)送cookie為galaxies.com，并可能導(dǎo)致未經(jīng)授權(quán)的狀態(tài)改變晕窑。使用同步令牌模式抑片，CSRF是可以預(yù)防的。這聽起來很復(fù)雜杨赤，但是所有現(xiàn)代的web框架都支持這個敞斋。
例如，AngularJS有一個解決方案去驗證疾牲，只能由你的域才能訪問cookie植捎。直接來自AngularJS文檔:
當執(zhí)行XHR請求時，$http服務(wù)從cookie中讀取令牌(默認阳柔，XSRF-TOKEN)并將其作為一個http頭(X-XSRF-TOKEN)焰枢。因為只有JavaScript運行在你的域才可以讀取cookie,你的服務(wù)器可以確信XHR來
自你的域中運行的JavaScript。通過包含一個xsrfToken JWT claim舌剂，你可以讓這個CSRF保護無狀態(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保護沒有開發(fā)工作霍转。
利用你的web應(yīng)用程序框架的CSRF保護荐绝，使得cookies存儲JWT絕對可靠。CSRF也可以從你的API中通過檢查HTTP Referer和原始header部分阻止避消。CSRF攻擊將有與應(yīng)用程序無關(guān)的Referer和原始heade低滩。
雖然他們更安全的存儲你的JWT，cookies可能導(dǎo)致一些開發(fā)商頭痛岩喷，這取決于你的應(yīng)用程序的運轉(zhuǎn)是否需要跨域訪問恕沫。只是知道cookies有附加屬性(域名/路徑)，可以對其進行修改纱意，從而允許你指定cookie的發(fā)送位置婶溯。使用AJAX，你的服務(wù)器端也可以通知瀏覽器證書(包含Cookies)是否應(yīng)該隨著CORS請求發(fā)送。
結(jié)論
JWTs是一個很棒的身份驗證機制爬虱。它們給你一個結(jié)構(gòu)化的方式聲明用戶和它們可以訪問的內(nèi)容∨荏荩可以對它們進行加密和簽名來防止在客戶端進行篡改死讹，但魔鬼在于細節(jié)和你把它們存放在哪里。
Stormpath建議你把JWT存儲到Web應(yīng)用程序的cookies中曲梗，因為他們提供的額外的安全性赞警，防止現(xiàn)代web框架CSRF的簡單性。HTML5 Web存儲很容易受到XSS攻擊虏两，有一個更大的攻擊面積愧旦，一個成功的攻擊會影響所有應(yīng)用程序的用戶。
