我的 API 金鑰設計冒險記

背景

本文作者分享了他在設計多租戶分片架構下的 API 金鑰系統時的心路歷程。在從開發運維轉向產品開發的過程中，他深入研究了 API 金鑰的格式設計、校驗和機制以及如何在高併發的分片資料庫環境中，透過金鑰前綴或編碼方式快速定位用戶所屬的資料庫分片。

社群觀點

針對作者提出的設計方案，Hacker News 的討論主要圍繞在 API 金鑰的功能性設計與安全性實踐。許多資深開發者指出，金鑰中包含前綴與校驗和的主要目的，並非僅是為了區分金鑰類型或減少資料庫查詢負擔，更關鍵的用途在於「機密掃描」。透過特定的前綴格式，安全掃描工具能輕易識別出被意外提交至程式碼庫的憑證並自動撤銷，而校驗和則能大幅降低掃描時的誤報率。

在技術實作層面，社群對於是否該在金鑰中嵌入資訊存在分歧。有觀點認為 API 金鑰應保持完全不透明，例如使用 UUIDv7 以避免任何資訊洩漏；然而，針對作者面臨的分片路由難題，也有人建議可以將帳號 ID 的雜湊值直接存入金鑰中，這樣在請求進入系統時，無需查詢中繼資料表即可直接定位分片，實現無狀態的路由。關於是否該使用 JWT 來替代傳統 API 金鑰，討論中出現了激烈的辯論。反對者認為 JWT 雖然能解決路由問題，但會引入複雜的過期與刷新機制，對於簡單的 API 存取來說過於沉重；支持者則強調 JWT 是成熟的標準，能避免自行開發加密邏輯可能導致的安全漏洞。

此外，針對金鑰的儲存安全性，社群達成了一項共識：API 金鑰應如同密碼一般進行雜湊處理後再存入資料庫，且不應以明文形式存在。由於 API 金鑰通常具有足夠的隨機熵值，開發者認為使用 SHA-256 等快速雜湊演算法已足夠安全，不一定需要像處理使用者密碼那樣使用 bcrypt 等高成本的演算法。最後，部分評論者提醒，一個完善的 API 金鑰系統除了生成與驗證外，更應具備無縫輪轉的能力，以應對金鑰洩漏時的緊急處理。

延伸閱讀

在討論中，有開發者推薦了 Sylvain Kerkour 撰寫的生產環境 API 金鑰實作指南，該文詳細介紹了如何處理版本控制、雜湊元數據以及防範混淆代理人攻擊等進階安全議題。此外，也有人分享了 Voiden 等 API 基礎設施工具作為設計參考。