內(nèi)容參考自：JWT：完全前后端分離的項目如何做用戶身份驗證更安全？看這篇就夠了！
JSON Web Token是什么？
JSON Web Token (JWT)是一個開放標(biāo)準(zhǔn)(RFC 7519)，它定義了一種緊湊的、自包含的方式，用于作為JSON對象在各方之間安全地傳輸信息。該信息可以被驗證和信任，因為它是數(shù)字簽名的。
JWT 結(jié)構(gòu)
Header 頭部
頭部包含了兩部分，token 類型和采用的加密算法
{
"alg": "HS256",
"typ": "JWT"
}
然后，用Base64對這個JSON編碼就得到JWT的第一部分
Base64是一種編碼，也就是說，它是可以被翻譯回原來的樣子來的。它并不是一種加密過程。
Payload 負(fù)載
這部分就是我們存放信息的地方了，你可以把用戶 ID 等信息放在這里，JWT 規(guī)范里面對這部分有進(jìn)行了比較詳細(xì)的介紹，常用的由 iss（簽發(fā)者），exp（過期時間），sub（面向的用戶），aud（接收方），iat（簽發(fā)時間）。
{
"iss": "dzl JWT",
"iat": 1441593502,
"exp": 1441594722,
"uid": "123dzlxxx",
"sub": "dzl"
}
同樣的，它會使用 Base64 編碼組成 JWT 結(jié)構(gòu)的第二部分
Signature 簽名
前面兩部分都是使用 Base64 進(jìn)行編碼的，即前端可以解開知道里面的信息。Signature 需要使用編碼后的 header 和 payload 以及我們提供的一個密鑰，然后使用 header 中指定的簽名算法（HS256）進(jìn)行簽名。簽名的作用是保證 JWT 沒有被篡改過。
三個部分通過.連接在一起就是我們的 JWT 了，它可能長這個樣子，長度貌似和你的加密算法和私鑰有關(guān)系。
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjU3ZmVmMTY0ZTU0YWY2NGZmYzUzZGJkNSIsInhzcmYiOiI0ZWE1YzUwOGE2NTY2ZTc2MjQwNTQzZjhmZWIwNmZkNDU3Nzc3YmUzOTU0OWM0MDE2NDM2YWZkYTY1ZDIzMzBlIiwiaWF0IjoxNDc2NDI3OTMzfQ.PA3QjeyZSUh7H0GfE0vJaKW4LjKJuC3dVLQiY4hii8s
其實到這一步可能就有人會想了，HTTP 請求總會帶上 token，這樣這個 token 傳來傳去占用不必要的帶寬啊。如果你這么想了，那你可以去了解下 HTTP2，HTTP2 對頭部進(jìn)行了壓縮，相信也解決了這個問題。
簽名的目的
最后一步簽名的過程，實際上是對頭部以及負(fù)載內(nèi)容進(jìn)行簽名，防止內(nèi)容被竄改。如果有人對頭部以及負(fù)載的內(nèi)容解碼之后進(jìn)行修改，再進(jìn)行編碼，最后加上之前的簽名組合形成新的JWT的話，那么服務(wù)器端會判斷出新的頭部和負(fù)載形成的簽名和JWT附帶上的簽名是不一樣的。如果要對新的頭部和負(fù)載進(jìn)行簽名，在不知道服務(wù)器加密時用的密鑰的話，得出來的簽名也是不一樣的。
信息暴露
在這里大家一定會問一個問題：Base64是一種編碼，是可逆的，那么我的信息不就被暴露了嗎？
是的。所以，在JWT中，不應(yīng)該在負(fù)載里面加入任何敏感的數(shù)據(jù)。在上面的例子中，我們傳輸?shù)氖怯脩舻腢ser ID。這個值實際上不是什么敏感內(nèi)容，一般情況下被知道也是安全的。但是像密碼這樣的內(nèi)容就不能被放在JWT中了。如果將用戶的密碼放在了JWT中，那么懷有惡意的第三方通過Base64解碼就能很快地知道你的密碼了。
因此JWT適合用于向Web應(yīng)用傳遞一些非敏感信息。JWT還經(jīng)常用于設(shè)計用戶認(rèn)證和授權(quán)系統(tǒng)，甚至實現(xiàn)Web應(yīng)用的單點登錄。
JWT 實現(xiàn)身份驗證
- 前端通過Web表單將自己的用戶名和密碼發(fā)送到后端的接口。這一過程一般是一個HTTP POST請求。建議的方式是通過SSL加密的傳輸（https協(xié)議），從而避免敏感信息被嗅探。
- 后端核對用戶名和密碼成功后，將用戶的id等其他信息作為JWT Payload（負(fù)載），將其與頭部分別進(jìn)行Base64編碼拼接后簽名，形成一個JWT。形成的JWT就是一個形同lll.zzz.xxx的字符串。
- 后端將JWT字符串作為登錄成功的返回結(jié)果返回給前端。前端可以將返回的結(jié)果保存在localStorage或sessionStorage上，退出登錄時前端刪除保存的JWT即可。
- 前端在每次請求時將JWT放入HTTP Header中的Authorization位。(解決XSS和XSRF問題)
- 后端驗證JWT的有效性。例如，檢查簽名是否正確；檢查Token是否過期；檢查Token的接收方是否是自己（可選）。
- 驗證通過后后端使用JWT中包含的用戶信息進(jìn)行其他邏輯操作，返回相應(yīng)結(jié)果。
和Session方式存儲id的差異
Session方式存儲用戶id的最大弊病在于Session是存儲在服務(wù)器端的，所以需要占用大量服務(wù)器內(nèi)存，對于較大型應(yīng)用而言可能還要保存許多的狀態(tài)。一般而言，大型應(yīng)用還需要借助一些KV數(shù)據(jù)庫和一系列緩存機(jī)制來實現(xiàn)Session的存儲。
而JWT方式將用戶狀態(tài)分散到了客戶端中，可以明顯減輕服務(wù)端的內(nèi)存壓力（Payload 中保存了用戶狀態(tài)）。除了用戶id之外，還可以存儲其他的和用戶相關(guān)的信息，例如該用戶是否是管理員、用戶所在的分組等。雖說JWT方式讓服務(wù)器有一些計算壓力（例如加密、編碼和解碼），但是這些壓力相比磁盤存儲而言可能就不算什么了。具體是否采用，需要在不同場景下用數(shù)據(jù)說話。
JWT注意事項
- JWT默認(rèn)不加密，但可以加密。生成原始令牌后，可以使用改令牌再次對其進(jìn)行加密。
- 當(dāng)JWT未加密方法是，一些私密數(shù)據(jù)無法通過JWT傳輸。
- JWT不僅可用于認(rèn)證，還可用于信息交換。善用JWT有助于減少服務(wù)器請求數(shù)據(jù)庫的次數(shù)。
- JWT的最大缺點是服務(wù)器不保存會話狀態(tài)，所以在使用期間不可能取消令牌或更改令牌的權(quán)限。也就是說，一旦JWT簽發(fā)，在有效期內(nèi)將會一直有效。
- JWT本身包含認(rèn)證信息，因此一旦信息泄露，任何人都可以獲得令牌的所有權(quán)限。為了減少盜用，JWT的有效期不宜設(shè)置太長。對于某些重要操作，用戶在使用時應(yīng)該每次都進(jìn)行進(jìn)行身份驗證。
- 為了減少盜用和竊取，JWT不建議使用HTTP協(xié)議來傳輸代碼，而是使用加密的HTTPS協(xié)議進(jìn)行傳輸。
