上一篇筆記講到了瀏覽器與伺服器之間,經過身分驗證後,就會改以 Token 這個令牌作為通行證,不需要再反覆驗證,那麼這篇紀錄的就是目前最常使用的 JWT (JSON Web Token) 啦!
可以搭配 JWT 的網站來玩看看
JWT(JSON Web Token) 顧名思義就是以 JSON 格式來製作的 Token,大概會長這樣
網站中很明顯用顏色和點號來區分 JWT 的三個部分,分別是 header(紅色)、payload(紫色) 和 signature(藍色)。
header 內會包含的資訊有 Token 的類型、使用何種演算法
{
"alg":"HS256" // 是用何種演算法產生的
"typ":"JWT", // token 的類型
}
payload 則包含了data 資訊,但不是機密資訊,這時候就需要先了解一下什麼是 payload 了,在 Payload究竟是什麼意思 文章裡,對於 payload 的舉例說明很清楚,這邊就大致節錄一下就好:
有位客戶委託貨車司機運送石油,並支付一筆「委託費用」,其中石油重量、貨車重量、司機重量...等都屬於載重 (load) 的一部分,但對於客戶而言,他關心的只有「石油的重量」,也就是他願意付費的重量,此時「石油的重量」就是有效載重 (payload)
因此我們可以將 payload 理解為,一系列訊息之中,比較重要的、關鍵的、使用者有興趣了解的資訊,在 JWT 裡面, payload 所包含的資訊有:
{
"sub":"12345678", // 識別訊息
"name":"Amberhh",
"iat":"15688543", // issued at 發行的時間
"exp":"19397765", // expired at 到期時間
... // 其他資訊
}
那為什麼 payload 裡面絕對不能放機密資訊?
是因為 header 和 payload 的資訊僅使用 base64 編碼進行包裝,避免非法字元,沒有加密的動作,是可以被反解譯的,如果 Token 沒有保存好不小心外流,被有心人士 decode 它的 base64 編碼,則機密資訊都會外流哦~
也因為 header 和 payload 都可以被反解譯,因此 JWT 的「簽章」部分,就是這個 Token 最安全的地方了!
簽章是將 header 和 payload 的訊息,以 base64 編碼組成一組字串,將這組字串加上私鑰加密,接著再將密文用雜湊演算法處理,變成不可反解譯的簽章
由於雜湊值是無法被逆向解碼的,且 header 和 payload 的資訊如果有更動,雜湊的 hash 值,也會改變,因此伺服器收到 JWT 後,會先將前兩部分 (header 和 payload),用共享的私鑰,進行前面說過的加密和雜湊處理,如果得到的結果與這支 JWT 的第三部分簽章相同,即可認定這個 Token 的合法性。
經過伺服器比對過的合法簽章,能確認使用者是同一人,達到無狀態驗證,也因為只有持有相同私鑰的合法伺服器可以解析和驗證這個 Token,同時也確保了 JWT 的完整性和真實性囉。
我是Amber,前端學習中,歡迎交流討論🧸