Most Devs Get API Authentication Wrong ?

Web API 認證的本質問題源自 HTTP 的無狀態性。HTTP 協議中每一個請求都是獨立事件，伺服器沒有任何記憶，這意味著用戶在第一個請求中驗證了身份，到了第二個請求（哪怕只隔半秒）伺服器一樣不認識你。認證（Authentication）要解決的是「你是誰」的問題，而授權（Authorization）是在「你已確認身份」之後才問「你能做什麼」。這兩件事順序固定，不可顛倒，而本影片聚焦在前者：如何在 HTTP 無狀態的前提下，每次請求都能可靠地証明身份。

最早的解法是 Basic Auth：將 username 與 password 用冒號拼接，再以 Base64 編碼後放進每個請求的 HTTP Header。重要的是，Base64 是「編碼」不是「加密」，任何人拿到字串都能秒解碼。因此 Basic Auth 的安全性完全依賴 HTTPS——HTTPS 將整條連線加密，外人根本碰不到那個可被解碼的字串。這個方案夠簡單、部署快、適合 CI/CD pipeline 或只有少數信任方使用的內部服務；但它的致命缺點是每次請求都帶上帳密，每次都是一次可能出錯的機會，因此公開 API 不適合使用。

Opaque Bearer Token 改善了這一點：用戶只在登入時傳一次帳密，伺服器驗證後回傳一個隨機字串（token），後續所有請求只帶這個 token 即可。概念上就像音樂節的手環——入場驗票一次，之後憑手環進出，不用每次再拿票。然而 Opaque Token 本身沒有任何語意，只是一串隨機字元，伺服器收到後必須去資料庫查詢「這個 token 屬於誰、有什麼權限」。單機架構下這沒問題，但當服務水平擴展成多個節點時，所有節點都需要共享同一個 token 資料庫或 Redis Cache，架構複雜度隨節點數線性增長。

JWT（JSON Web Token）正是為了解決這個擴展問題而生。JWT 由三段組成：Header（聲明演算法與 token 類型）、Payload（攜帶用戶 ID、角色、過期時間等聲明）、Signature（對前兩段做加密簽名）。伺服器收到 JWT 後只需用密鑰做數學運算驗證簽名，無需查詢任何資料庫。一旦簽名驗証通過，Payload 中的所有信息即可直接信任使用。這使得任何持有相同 secret（或 public key）的服務器都能獨立驗證 token，天然支持橫向擴展。但 JWT 有個根本限制：token 不存在伺服器端，一旦發出就活在客戶端，即使帳號被盜也無法即時撤銷，只能等到 token 自然過期。這也是為何 JWT 的過期時間必須短，建議 15 分鐘。

短效 token 帶來新問題：用戶豈不是要每 15 分鐘登入一次？解法是 Refresh Token 模式：同時發出兩個 token，短效 JWT（15 分鐘）用於每次 API 請求，長效 Opaque Refresh Token（7 天）存在資料庫，只在 Access Token 過期時用來靜默換新 JWT。這樣用戶無感，但長效 token 因為存在資料庫，隨時可以撤銷。在演算法選擇上，單一伺服器使用對稱式 HMAC-SHA256 即可；微服務架構則應採用非對稱式 RS256，Auth Server 持有 private key 簽發 token，其餘服務只需 public key 驗證，private key 永不外流。最後，安全上還需防範 `alg: none` 攻擊——攻擊者將 Header 中的演算法改為 `none`，讓伺服器跳過驗証；防禦方法是在驗証邏輯中明確白名單指定可接受的演算法（如只允許 RS256），一行設定即可徹底封堵。