JWT,全名為JSON Web Token (RFC 7519),它定義了一種簡潔且自包含的方式,將訊息作為JSON 物件傳輸,並且該訊息會經過數位簽章(Digital Signature),因此是可以被驗證及信任的。
JWT 的組成分為Header
、Payload
、Signature
三個JSON Object,這三個部分會先各自進行編碼再用.
間隔,最後組成一個JWT 字串。
第一個部分是Header 標頭,又稱為JOSE Header,這個部分由兩個欄位組成。
alg (algorithm)
: 必要欄位,對於JWT 進行簽章或解密的主要演算法,如HMAC、SHA256、RSA 等,對於未加密的JWT 則設置為none
。typ (type)
: 非必要欄位,宣告這個JWT 的媒體類型,基本上就是JWT。cty (content type)
: 非必要欄位,傳達有關JWT 的結構訊息,一般情況下,不允許使用巢狀簽章或加密方法,因此這個欄位並不常見。{
"alg" : "HS256",
"typ" : "JWT"
}
再來就是Payload 內容,這裡放的是聲明(Claim)內容,也就是存放要傳遞的訊息的地方,通常所有資訊都會被放在這裡。
iss (Issuer)
: JWT 的簽發人。sub (Subject)
: JWT 的主題。aud (Audience)
: JWT 的受眾。exp (Expiration Time)
: JWT 的過期時間。nbf (Not Before)
: 定義在發放JWT 之後的某個時間點前,該JWT 無法使用。iat (Issued At)
: JWT 的簽發時間。jti (JWT ID)
: JWT 的身分標示,每個JWT 的ID 不應該重複,避免重複發放。最後是Signature 簽章,它是由前兩個部分Header 和Payload 分別Base64 編碼後再用.
串接,接者和一個密鑰經過加密演算法後取得,而擁有Signature 的JWT 就會被稱為JWS,也就是有簽名的JWT,沒有Signature 的JWT 也被稱為Unsecured JWT,也就是不安全的JWT,代表Header 中的alg
為none
JWS,全名為JSON Web Signature (RFC 7515),它算是JWT 最廣泛使用的功能,透過將簡單的資料格式與定義明確的簽章演算法結合,使JWT 成為安全共享數據的理想格式。
簽章的目的是允許一個或多個參與方建立JWT 的真實性,可以讓我們驗證Token 是否有效或被竄改,也就是說,可以執行簽章檢查的任何一方都可以取得JWT 提供的內容,並不會阻止任何一方讀取JWT 中的內容。
另外,若是具有公私鑰的簽章方式,如RSA 等,私鑰可以新增資訊並驗證其真實性,而公鑰只能驗證資訊的真實性,因此使用公私鑰簽章方式的JWS 可以允許一對多的安全分發訊息,Audience
可以透過公鑰驗證資料的真實性,但不能使用它創建新訊息,如下圖(圖片來源是誰在敲打我窗?什麼是 JWT ?)。
而若是使用共享秘密的簽章方式,如HMAC 等,則會因為可以驗證資訊的任何一方也可以新增資訊,當合法用戶變成惡意用戶時,惡意用戶就可以修改訊息而不被其他方注意。
既然上面提到了JWS,那就不得不提一下JWE。
JWE,全名為JSON Web Encryption (RFC 7516),相對於JWS 是提供了一種驗證數據的方法,而JWE 則是提供了一種保護資料使數據對第三方不透明的方法,不透明的意思就是不可讀,在這種情況下,加密的Token 不能由第三方檢查。
在JWS 中,擁有私鑰的一方可以簽章和驗證Token,而持有公鑰的各方只能驗證Token,但在JWE 中,擁有私鑰的是唯一可以解密Token 的一方,也就是說,持有公鑰的Issuer
只能加密數據,持有私鑰的Audience
才能加密和解密數據,如下圖(圖片來源是誰在敲打我窗?什麼是 JWT ?)。,
是誰在敲打我窗?什麼是 JWT ?
JWT(JSON Web Token) - 原理介紹
JWT & JWE & JWS 大亂鬥!