why JWT
現(xiàn)在，前后端分離和 RESTful API 越來越火熱，當(dāng)后臺漸漸開始只負責(zé)為客戶端提供 API 接口之后，身份校驗和接口安全成了難題。在傳統(tǒng)的開發(fā)模式下，使用 cookie-session 可以保證接口安全，在沒有登錄的情況下訪問關(guān)鍵數(shù)據(jù)會跳轉(zhuǎn)到登錄界面或者請求失敗。而使用 REStful API 之后，cookie-session 存在以下 3 個問題：
- 客戶端除了瀏覽器，可能還包括手機端 APP，對于手機端而言，管理 cookie 是一件麻煩的事情。
- RESTful 風(fēng)格的 API 不建議使用 cookie。
- cookie 本身有一個缺陷，不能跨域。
正是存在上面的幾個缺陷，現(xiàn)在 API 開始使用 JWT 代替 cookie-session 來做身份驗證。
what JWT
JWT 全稱 JSON Web Token。本質(zhì)上 JWT 是一串 token 字符串。客戶端登錄之后，服務(wù)端返回一串 token 給客戶端，之后每次客戶端請求 API 接口都需要攜帶該 token 進行身份校驗。JWT 由三個部分組成：頭部(header)、載荷(payload)、簽名(signature)。這三個部分使用 . 連接在一起就是一個完整的 JWT。所以，一個完整的 JWT 應(yīng)該類似下面這種形式：
xxxxxx.yyyyy.zzzzz
header
header 是一個 json 數(shù)據(jù)，用于描述 JWT 的基本信息。一般要由兩個部分組成：
- alg
- typ
alg 代表的是加密所使用的算法（后面會提到加密數(shù)據(jù)），typ 表示該 token 是什么類型的。這里 typ 自然是 JWT。
{
'alg':'HS256',
'typ':'JWT'
}
一個完整的 header 信息。最后使用 Base64 對 header 進行編碼，得到 JWT 的第一部分。
payload
payload 是 JWT 存儲信息的部分。payload 也是一個 json 數(shù)據(jù)，每一個 json 的 key-value 稱為一個聲明。
payload 有兩種類型的聲明：標準聲明和自定義聲明。
標準聲明一共有 6 個，其名稱和對應(yīng)含義如下：
-
iss: JWT 的簽發(fā)者。 -
iat: JWT 的簽發(fā)時間，是一個 unix 時間戳。 -
exp: JWT 的過期時間，是一個 unxi 時間戳。 -
aud: 接受 JWT 的一方。 -
sub: JWT 所面向的用戶。 -
jti: 唯一標識一個 JWT。
自定義聲明為用戶自己定義的 key-value，可以用來存儲一些簡單的基本信息。考慮到性能，不應(yīng)該在 payload 中定義太多自定義聲明。
定義一個 payload ：
{
"iss": "jaychen",
"iat": 1441593502,
"exp": 1441594722,
"aud": "jaychen.cc",
"sub": "chenjiayaooo@gmail.com",
"jti:" "xxxxxxxx",
"user_id": "1",
"username": "jaychen"
}
上面這個 payload 中，id 和 username 為自定義聲明。
有了 payload 只有，將該 payload 進行 Base64 加密，得到一串字符串之后，用 . 把 header 和 payload 連接起來。
signature
將 header 和 payload 兩個部分連接起來之后，得到的字符串類似下面
xxxxx.yyyyy
接著，使用 header.alg 定義的加密算法對 hader.payload 的字符串進行加密，并且加密的時候應(yīng)該有一個密鑰。加密之后，得到一串加密字符串，最后把這串加密字符串也是用 . 拼接在 header.payload 后面，形成完整的 JWT。
這里簽名的目的是為了保證 payload 數(shù)據(jù)的完整性。如果 JWT 在傳輸過程中被第三方劫持，中間人對 header.payload 進行修改，并且使用自己的密鑰重新簽名。服務(wù)端收到中間人修改過的 JWT，使用自己的密鑰對 header.payload 進行再次加密，由于中間人和服務(wù)端使用的是不同的密鑰簽名，所以服務(wù)端再次加密的結(jié)果肯定和中間人加密的結(jié)果不一致，由此可以斷定該 JWT 被惡意篡改。
基于 JWT 的身份驗證
現(xiàn)在已經(jīng)明白了 JWT 的生成過程，現(xiàn)在來梳理下 JWT 的使用流程。
- 首次登陸系統(tǒng)，向服務(wù)端發(fā)送 username&&password 進行登錄。
- 服務(wù)端驗證 username&&password,驗證合法為客戶端生成一串 JWT，這里在 payload 中可以自定義聲明 user_id,username 等字段用來保存信息。
- 客戶端收到服務(wù)端的 JWT 字符串，自行保存。后續(xù)需要請求 API 都要攜帶該 JWT 到服務(wù)端進行身份校驗。
- 服務(wù)端收到客戶端的 API 請求，先獲取 JWT 信息，通過簽名判斷 JWT 的合法性，如果合法，返回數(shù)據(jù)。
JWT 的優(yōu)點和注意事項
注意事項
上面生成 JWT 的過程中使用了 Base64 的加密算法對 payload 進行加密，Base64 是一種可逆的加密算法，這意味著其他人可以輕易的從加密結(jié)果中得到加密之前的信息，所以這注定了 payload 中不能保存密碼之類的敏感信息。
優(yōu)點
回顧上面生成 JWT 的步驟，payload 中我們保存了 user_id 和 username 這樣的信息。在傳統(tǒng)的 cookie-session 中，這些數(shù)據(jù)是服務(wù)端在 session 中維護的。JWT 把之前需要在服務(wù)端維護的 session 數(shù)據(jù)轉(zhuǎn)移到客戶端，使得服務(wù)端的壓力小了很多。
JWT 本質(zhì)只是一串字符串，所以可以無限制的使用各種姿勢傳遞給服務(wù)端：當(dāng)做 get 參數(shù)拼接在 URL 中、添加到 header 頭部中、當(dāng)做 post 參數(shù)傳遞。。。
如果客戶端是手機 APP 等非瀏覽器客戶端，那么使用 JWT 就可以免去對 cookie 的管理。
本文首發(fā)于：https://jaychen.cc
作者：jaychen
