JWT 詳解：結構、聲明和如何解碼

如果你用過現代 Web API，就見過 JWT —— 那些帶兩個點、出現在登入回應和 Authorization 標頭裡的一長串亂碼。它們看著不透明，但只要你知道結構，就出奇地好讀。本指南講清什麼是 JSON Web Token、裡面有什麼、簽章如何運作，以及要避免的安全錯誤。

JWT 是做什麼用的

JSON Web Token（JWT） 是一種緊湊、自包含的方式，用來攜帶一組聲明 —— 諸如「這是使用者 42，他在 10:05 登入」這樣的陳述。它的主要用途是身分驗證：你登入後，伺服器簽發一個 JWT，你的應用在每次請求時把它帶回，伺服器就信任它，而不必每次都去工作階段儲存裡查你。因為權杖本身攜帶資訊，所以被稱為 無狀態（stateless）。

三個部分

每個 JWT 都是三段用點連接的 Base64URL 編碼段：header.payload.signature。

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI0MiJ9.3x9kQ...
└──── header ────┘ └── payload ──┘ └ signature ┘

1. 標頭（Header）

關於權杖的中繼資料 —— 簽章演算法（alg，例如 HS256）和類型（typ: JWT）。解碼後，它只是一小段 JSON：

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

2. 酬載（Payload）

聲明 —— 實際的資料。有些名字是標準化的（稱為註冊聲明）：

• sub —— 主體（subject），通常是使用者 ID。
• iss —— 簽發者（issuer），誰建立了權杖。
• aud —— 受眾（audience），它是給誰的。
• exp —— 過期時間（一個 Unix 時間戳記）。
• iat —— 簽發時間（一個 Unix 時間戳記）。

那些 exp 和 iat 的值是自 1970 年以來的秒數 —— 如果你需要把它們讀成真實日期，時間戳記轉換器 會把它們變成人類可讀的時間。

3. 簽章（Signature）

簽章是讓權杖可信的東西。簽發者拿著標頭和酬載，用一個密鑰產生一個加密簽章。持有密鑰的任何人都能驗證標頭和酬載沒有被竄改 —— 只要改動酬載裡的一個字元，簽章就不再匹配。

最重要要理解的一點

JWT 是被簽章的，不是被加密的。 標頭和酬載只是被 Base64URL 編碼，這意味著 任何人 都能解碼並讀取它們 —— 無需密鑰。簽章防止 竄改，而不是 讀取。

實際後果：永遠不要把機密放進 JWT 酬載。沒有密碼、沒有信用卡號、沒有私密資料 —— 假設酬載是公開的。你可以把任意權杖貼進我們的 JWT 解碼器 親自確認，它會即時讀出標頭和聲明，全程在你的瀏覽器中（權杖絕不離開你的裝置）。底層不過是 Base64 解碼 —— 解碼器只是替你省了這些步驟。

驗證 vs. 解碼

這是兩種不同的動作，把它們搞混是一個真實的安全漏洞。解碼 讀取酬載 —— 任何人都能做，且什麼也證明不了。驗證 用密鑰檢查簽章，確認權杖是真實且未被改動的。伺服器在信任之前必須 驗證 每一個權杖；只解碼不是身分驗證。

常見陷阱

• 信任一個未經驗證的權杖 —— 在依據聲明行動前，務必在伺服器端檢查簽章。
• 忽略過期 —— 尊重 exp；一個過期的權杖應當被拒絕。
• 把敏感資料存進酬載 —— 它對任何人可讀。
• `alg: none` 陷阱 —— 一些函式庫曾經接受宣稱「無簽章」的權杖。拒絕它們，並鎖定預期的演算法。

理解這些，JWT 就從嚇人的字串變成一個簡單、透明的格式：可讀的聲明，由一個你必須在信任前驗證的簽章來保護。