什麼是 API 金鑰？
API 金鑰用於識別和授權呼叫應用程式或服務。它們通常是長期有效且靜態的，直到被旋轉，並且通常具有一組固定的權限。它們主要用於伺服器到伺服器的通信或訪問公共數據，這些令牌通常不代表特定用戶。
API 金鑰如何運作？
API 金鑰是一串由 API 提供者生成並與授權用戶共享的長字符串。訪問 API 時，必須將此金鑰包含在請求標頭中。API 金鑰對於基本安全需求來說簡單且有效。例如，像 Google Maps API 和 AWS 這樣的熱門服務提供 API 金鑰來控制訪問和監控使用情況。
curl -GET https://api.example.com/endpoint -H "Authorization: api-key YOUR_API_KEY"
API 金鑰不如其他形式的 API 認證 (Authentication) 有效，例如 OAuth 2.0 和 JSON Web Token (JWT) ，但它們在幫助 API 生產者監控使用情況方面仍然發揮著重要作用，因為這是保護 API 的最簡單和廣泛使用的方法。
它的優缺點是什麼？
優點
- 實施簡單：API 金鑰易於實施和使用。它們涉及將金鑰附加到請求標頭，這對於開發人員和客戶端來說是一種簡單明瞭的方法。
- 易於監控：API 金鑰易於監控。你可以跟踪每個金鑰的使用情況，並在必要時撤銷它們。
- 有效的速率限制：API 金鑰對於速率限制是有效的。你可以設置每個金鑰的請求數限制以防止濫用。
- 適用於非敏感數據：API 金鑰適用於非敏感數據或公開可用的 API，安全要求較低。
缺點
- 安全性有限：API 金鑰對於敏感數據來說不夠安全，尤其是對於客戶端應用程式。它們通常用於機器對機器的通信。
- 不適合用戶認證 (Authentication)：API 金鑰與應用程式或系統相關，而不是個別用戶，這使得識別特定用戶或跟踪其行為變得具有挑戰性。
- 沒有令牌過期：API 金鑰通常是靜態的，不會過期。如果金鑰被洩露，可能會被無限期濫用，除非手動重新生成。
API 金鑰的使用案例是什麼？
- 服務到服務的通信：API 金鑰適用於應用程式需要通過 CLI 直接與 API 通信的場景。例如，調用 OpenAI API。
- 公共 API：當向公眾公開 API 時，API 金鑰提供了一種簡單的訪問控制方法。
- 簡化設置：對於快速和簡單的認證 (Authentication) 需求，尤其是在開發階段。與機器對機器認證 (Authentication) 不同，API 金鑰不需要事先進行客戶端註冊，也不需要交換訪問令牌 (Access Token)。你只需在請求中將 API 金鑰作為參數傳遞，它就能正常工作。
在現實世界的場景中，構建產品時最常見的目的是產品集成。以下是一個典型的使用案例：
示例：與 Stripe 集成
Stripe 使用 API 金鑰與不同平台和應用程式進行安全集成。你可以通過開發者儀表板創建、查看、刪除和管理這些金鑰。通過使用 API 金鑰，你可以將 Stripe 的結帳和計費功能集成到你的產品中。
個人訪問令牌 (PAT) 和機器對機器 (M2M) 之間的區別是什麼？
談到 API 金鑰，個人訪問令牌和 機器對機器 (Machine-to-machine) 也可以一起提及，因為它們都可以通過 CLI 命令以編程方式訪問 API 資源，或在後端服務之間建立通信。
個人訪問令牌 (PATs)
個人訪問令牌也是一個字符串，但代表特定用戶的身份和權限，並在成功認證 (Authentication) 或登錄後動態生成，通常具有有限的壽命但可以刷新。它提供對用戶特定數據和功能的細粒度訪問控制，通常用於 CLI 工具、腳本或個人 API 訪問。主要區別在於它更具針對性，用於用戶特定的操作。
機器對機器 (M2M)
M2M 通信是指設備在更廣泛的意義上自動交換數據而無需人工干預。
在 OpenID Connect (OIDC) （或 OAuth 2.0 ）的上下文中，M2M 應用程式使用 委託流程 (Client credentials flow) ，如 OAuth 2.0 RFC 6749 協議 中所定義，支持類似的標準協議。它通常涉及客戶端應用程式（機器或服務）自行或代表用戶訪問資源。這對於只有受信任的客戶端可以訪問後端服務的情況是理想的。