JWT 概觀
密碼管理在討論的主要以使用者所輸入的密碼為主,而有另一種類似密碼用途的字串,也用在身分驗證上,正是 token。接下來會來討論最近不少人在使用的 JWT,它是一個開放標準,可以用在需要安全交換資料的場景上。
JWT 相關的 RFC 有下列五個,是由 JOSE(JSON Object Signing and Encryption)Working Group 所制定的。
- RFC 7515 - JSON Web Signature(JWS)
- RFC 7516 - JSON Web Encryption(JWE)
- RFC 7517 - JSON Web Key(JWK)
- RFC 7518 - JSON Web Algorithms(JWA)
- RFC 7519 - JSON Web Token(JWT)
其中 JWS 是定義如何做帶有簽章的 token,JWE 則是定義內容加密的 token,而 JWK 與 JWA 則是在金鑰的格式以及演算法,最後 JWT 則是定義了 header 內容與 claim 內容,以及 token 的相關規範。
就概念上而言,JWS 與 JWE 都是屬於 JWT 的一種。雖然有 JWE 在定義加密,但實務上的應用大多以 JWS 為主,因為在網路上交換資訊時,確認訊息來源以及資料完整性是很重要的,而 JWE 目前還沒看過。
未來如果沒特別說明,則 JWT 皆是指 JWS。
適合場景:
- 授權。在驗證通過後,即可發行 JWT 來進行使用者後續的資源請求
- 資訊交換。,因它可以保證資訊的來源與完整性,很適合作資訊交換
基本概念
無論是 JWS 或是 JWE,格式都是多組 Base64UrlEncode 過後的字串,用 .
串接而串的,比方說 JWS 就會長像下面這個範例:
xxx.yyy.zzz |
結構是一個字串,由兩點 .
來分隔出多個區塊,第一個區塊 xxx
稱之為 JOSE Header;第二個區塊 yyy
則是 JWS Payload。第三個 zzz
則是 JWS 專屬的 JWS Signature。JWE 也會有 JOSE Header 與夾帶的資料,只是資料是密文(JWE Ciphertext)。
每個區塊都是 Base64UrlEncode
來的。Base64UrlEncode
與 Base64Encode
稍有不同,簡單來說,Base64UrlEncode
比 Base64Encode
多做了下面的事:
=
刪光光+
換成-
/
換成_
JOSE Header
JOSE Header 會有下面這些 key
- 類型(typ),通常就叫
JWT
- 演算法(alg),常見的如
HS256
、RS256
等 - 加密演算法(enc)
{ |
JWS Payload
JWS Payload 則是存放 claim,代表著實體或使用者相關的資訊。有三種類型:
- Registered Claims:RFC 7519 裡預定義的 claim
- Public Claims:在 IANA JSON Web Token Registry 上註冊的名稱
- Private Claims:不屬於上述兩個 claim,則是 Private Claims。但如果 Public Claims 有適合的 claim,優先使用 Public Claims 較好。
比方說:
{ |
在此例中:
sub
是 Registered Claimsname
是 Public Claimsadmin
是 Private Claims
Registered Claims 可以參考下表:
Column | Full name | 中文 |
---|---|---|
iss |
Issuer | 發行人 |
sub |
Subject | 對象 |
aud |
Audience | 收件人 |
exp |
Expiration Time | 到期時間 |
nbf |
Not Before | 時間之前不處理 |
iat |
Issued At | 發行時間 |
jti |
JWT ID | JWT 的唯一識別碼 |