JWT 概觀

第 11 屆 iThome 鐵人賽

DAY 18

Security

我是誰？我在哪？系列第 18 篇

11th鐵人賽

Miles

2019-10-04 23:28:33

8463 瀏覽

分享至

密碼管理在討論的主要以使用者所輸入的密碼為主，而有另一種類似密碼用途的字串，也用在身分驗證上，正是 token。接下來會來討論最近不少人在使用的 JWT，它是一個開放標準，可以用在需要安全交換資料的場景上。

JWT 相關的 RFC 有下列五個，是由 JOSE（JSON Object Signing and Encryption）Working Group 所制定的。

其中 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）

{
  "alg": "HS256",
  "typ": "JWT"
}

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": "1234567890",
  "name": "John Doe",
  "admin": true
}

在此例中：

sub 是 Registered Claims
name 是 Public Claims
admin 是 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 的唯一識別碼