身分驗證與資安指南
JSON Web Token (JWT) 資安防護手冊
深入了解 RFC 7519 規範、標頭攻擊防禦、簽名演算法選型（HS256 vs RS256）及無狀態身份驗證防禦策略。
RFC 7519 標準宣告 (Registered Claims) 速查表
| Claim 欄位 | 完整名稱 | 作用說明 | 範例代碼 |
|---|---|---|---|
| iss | Issuer (簽發者) | 識別核發此 Token 的機構或服務端網址 | "iss": "https://auth.company.com" |
| sub | Subject (主體) | Token 所代表的唯一識別代碼（通常為 User ID） | "sub": "usr_998877" |
| aud | Audience (受眾) | 預期接收並信任此 Token 的 API 服務目標 | "aud": "https://api.company.com" |
| exp | Expiration Time (過期時間) | Unix 秒級時間戳記，超過即自動失效 | "exp": 1792400000 |
| nbf | Not Before (生效時間) | 在此時間戳記到達前，Token 不得被接受 | "nbf": 1760000000 |
| iat | Issued At (簽發時間) | Token 建立與簽署的時間戳記 | "iat": 1760000000 |
| jti | JWT ID (唯一編號) | 此 Token 的隨機唯一識別碼，常用於防重放攻擊 | "jti": "d3b07384-d113" |
JWT 開發生產環境 5 大防禦防坑指南
1. 絕對不要在 Payload 存放機密明文
JWT Payload 僅是 Base64Url 編碼，任何取得 Token 的人皆可直接解碼出明文。切勿將使用者明文密碼、身分證字號、信用卡號等敏感資料放入 Claims。
2. 嚴格鎖定簽名演算法（防禦 None 漏洞）
惡意攻擊者常竄改 Header 中的 "alg": "none" 嘗試繞過後端驗證。伺服器必須強制指定驗證演算法（如嚴格僅接受 HS256 或 RS256）。
3. 短效 Access Token 搭配 Refresh Token
因無狀態 JWT 無法輕易自伺服器主動銷毀，應將 Access Token 效期縮短（例如 15 分鐘），並使用安全儲存於 HttpOnly Cookie 的 Refresh Token 進行背景換發。
4. HS256 與 RS256 演算法選型建議
單體應用可使用對稱式 HS256（密鑰長度至少 256 位元隨機字串）；在微服務架構中，建議採用非對稱式 RS256/ES256，由認證伺服器持私鑰簽發，各微服務以公開公鑰驗證。