個人訪問權杖、機器對機器驗證和 API 金鑰的定義及其實際應用場景

如果你在構建一個軟體或 SaaS 產品，你經常會遇到一個廣泛的用例或功能需求：API 請求。尤其是大型企業客戶，可能希望在個人或組織層面上以程式化方式訪問資源。

在這些情況下，通常需要 API 金鑰、個人訪問權杖 (PATs) 和機器對機器 (M2M) 驗證。在本文中，我們將探討這些方法之間的差異，以及在 B2B 產品開發中，這些方法如何被開發者使用。

相似之處#

首先來看看這三者之間的相似性。

1. 安全目的： 這三種方法都用於保護和控制對 API、服務或資源的訪問。它們都作為驗證和/或授權的手段。
2. 基於令牌的方法： 每種方法通常都涉及使用一個唯一的字符串或令牌進行識別。這些令牌通常與 API 請求一起發送，通常在標頭或作為查詢參數。
3. 可吊銷： 所有三種方法中的令牌或金鑰如果被泄露或不再需要，可以被吊銷或無效化。這樣可以快速做出安全響應，而不需要更改基礎系統。
4. 可程式化訪問： 所有三種方法都促進對 API 或服務的程式化訪問。它們使不同系統或應用之間的自動化和集成成為可能。
5. 可審計： 這些驗證方法的使用可以被記錄和審計。這允許追踪 API 訪問，監控可疑活動，並進行合規報告。
6. 適應訪問控制： 所有三種方法都可以以不同程度的訪問控制和權限實施。它們可以適應不同的安全模型和架構需求。
7. 協議獨立性： 雖然通常用於 REST API，這些方法可以應用於各種類型的 API 和協議。

瞭解這些相似之處有助於認識到這些驗證方法的共同基礎。它們的差異允許你為特定的用例和安全需求選擇最合適的解決方案。

現在，讓我們討論它們的差異，聚焦于它們的用例以及何時使用每種方法。

差異之處#

API 金鑰#

API 金鑰用於識別和授權呼叫應用或服務。它們通常是長期有效且靜態的，直到進行旋轉，並且通常具有固定的一組權限。它們主要用於服務器對服務器的通信或訪問公共數據，這些令牌通常不代表特定用戶。

API 金鑰如何運作？#

API 金鑰由 API 提供商發行並提供給註冊的 API 使用者 [1]，該消費者在每次請求時都會包含在內。API 服務器然後檢查 API 金鑰以驗證消費者的身份，然後返回請求的數據。

API 金鑰不像其他 API 驗證 形式那麼有效，例如 OAuth 和 JWT，但它們仍然在幫助 API 生產者監控使用情況同時保持敏感數據安全方面發揮重要作用。

[1]: API 使用者是與 API 互動以訪問其功能或數據的任何應用、服務或用戶。他們向 API 發送請求以執行操作，例如檢索、創建、更新或刪除資源。API 使用者可以是 Web 應用、移動應用、其他服務器，甚至是個別開發人員，他們使用 API 來集成其他服務或在現有平臺上構建新功能。

Postman: 什麼是 API 金鑰？

用例#

當提到 API 金鑰的用例時，經常提到自動化、數據共享、測試、開發和安全控制。然而，這些相當技術化。在現實世界的場景中，構建產品時最常見的目的是集成。

範例 1：與 Zapier 整合#

Zapier: 添加 API 金鑰進行驗證

Zapier 是一個流行的自動化工具，可以連接不同的 web 應用。在與 Zapier 整合應用時，API 金鑰用於驗證和授權對應用 API 的訪問。例如，如果你想在 CRM 系統和電子郵件行銷工具之間自動化任務，你將從 CRM 系統生成一個 API 金鑰並提供給 Zapier。這個金鑰然後被用來驗證從 Zapier 到 CRM 的 API 請求，允許兩個系統之間的数据安全流动。

範例 2：與 Stripe 整合#

Stripe 利用 API 金鑰來安全地與各種平臺和應用整合。使用 開發者儀錶板 創建、揭示、刪除和轉動 API 金鑰。

個人訪問權杖 (PATs)#

個人訪問權杖是另一個類似的概念，但代表特定用戶的身份和權限，它是在成功驗證或登入時動態生成的，通常具有有限的壽命但可以刷新。它們為用戶特定數據和能力提供精細的訪問控制，並且通常用於 CLI 工具、腳本或個人 API 訪問。

PATs 如何運作#

1. 創建和管理： 用戶通過其帳戶設置在相應平臺上生成 PATs。
   • 例如，在 GitHub 中，用戶可以創建具有特定權限和到期日期的精細化或經典 PATs。
   • 在如 Jira 和 Confluence 的 Atlassian 產品中，用戶可以從其個人資料設置創建 PATs，指定令牌的名稱和可選的到期時間。
2. 使用： PATs 作為持有者令牌在 API 請求的授權標頭中使用。這意味著它們被包含在 HTTP 標頭中驗證請求。
   • 它們允許安全訪問 API 資源，允許用戶根據令牌授予的權限執行諸如創建、閱讀、更新和刪除資源等操作。
   • PATs 可以跨平臺內的多個應用使用，提供一種統一的方式來管理訪問和權限。
3. 吊銷和設置到期：
   • PATs 提供增強的安全性，允許用戶如果令牌被泄露，可以吊銷令牌，而不需要改變帳戶密碼。
   • 平臺通常建議為 PATs 設置到期時間以減少長期令牌被利用的風險。

用例#

有兩個典型場景，

自動化和腳本編寫

這意味著當開發者使用 PAT 自動化將代碼從存儲庫部署到生產環境時，減少手動干預並確保一致性。

例如，GitHub 用戶可以創建 PATs 來驗證 HTTPS 上的 Git 操作並與 GitHub 的 REST API 互動。這對需要自動化任務如克隆存儲庫、推送提交或管理問題和拉取請求的開發者很有用。

與外部應用整合

這意味著使不同系統和應用之間的安全通信成為可能。這看起來與 API 金鑰集成的場景相似，但 PAT 代表的是用戶，而不是客戶端或應用。

例如，專案經理使用 PAT 將專案管理工具與外部問題追蹤系統整合，允許無縫的数据交換和同步，如 Atlassian（Jira 和 Confluence）。

以上場景更像是開發工具。PATs 僅適用於這些類型的產品嗎？不。這裡有兩個額外的例子：一個是 CMS 系統，一個是生產力工具。

範例 1：Contentful#

Contentful: 個人訪問權杖

Contentful 是一個 headless CMS 平臺，提供 PATs 作為訪問其內容管理 API (CMA) 的 OAuth 令牌替代品。

主要特點包括：

• 用戶可以創建具有不同範圍和權限的多個令牌。
• 令牌與用戶的帳戶綁定，繼承其權限。
• PATs 特別適合開發和自動化用途。

範例 2：Airtable#

創建個人訪問權杖 | Airtable 支援

Airtable——一個雲端協作平臺，為 API 訪問實施 PATs。

其系統允許：

• 創建具有不同範圍和訪問級別的多個令牌。
• 令牌可以限制在特定的基地或工作區。
• 企業管理員可以創建具有整個組織更廣泛訪問的令牌。

機器對機器 (M2M) 驗證#

M2M 是為服務對服務的通信而設計的，不需要人工干預。它源於用戶名和密碼不足以保護服務，且對有效的自動化而言效率不足的理念。

機器對機器 (M2M) 應用現在採用客戶端信任流，這在 OAuth 2.0 RFC 6749 授權協議 中定義。它還可以支持類似的標準協議。是的，與 PATs 和 API 金鑰相比，M2M 驗證對開放標准更為嚴格。

它驗證應用或服務本身，而不是用戶，並且通常實施 JSON Web Tokens (JWT) 進行無狀態驗證。這為服務之間在分佈式系統中的互動提供了一個安全的方式。

機器對機器驗證如何運作#

它遵循類似的過程：

1. 客戶端憑證： 每台機器（或服務）都有一個唯一的客戶端 ID 和密鑰。
2. 令牌請求： 服務向授權服務器發送這些憑證。
3. 訪問令牌： 經驗證後，授權服務器發行一個訪問令牌，通常是 JWT（JSON Web Token）。
4. API 請求： 服務使用此令牌來驗證和授權對另一服務的 API 請求。
5. 驗證： 接收服務驗證令牌後，授予資源訪問權。

用例#

這裡有一個後端對後端通信中使用機器對機器 (M2M) 驗證的簡明例子：

場景：服務 A 需要訪問服務 B 的 API 數據。

1. 設置：

   • 服務 A 作為客戶端在授權服務器上註冊。
   • 為服務 A 提供客戶端 ID 和客戶端密鑰。

2. 驗證：

   • 服務 A 向授權服務器請求訪問令牌：

3. 令牌發行：

   • 授權服務器驗證憑證並發行 JWT 訪問令牌。

4. API 請求：

   • 服務 A 使用此令牌向服務 B 請求數據：

5. 驗證：

   • 服務 B 向授權服務器驗證令牌。

6. 回應：

   • 若有效，服務 B 返回請求數據給服務 A。

此過程允許服務 A 和服務 B 之間在無需用戶干預的情況下進行安全、自動的通信，使用 OAuth 2.0 客戶端憑證流。

設備對設備通信

設備對設備通信，尤其是在物聯網 (IoT) 的背景下，嚴重依賴於機器對機器 (M2M) 驗證以確保數據交換的安全和高效。

例如，像智能家居設備，一個智能恒溫器與中央家庭自動化中心通信，以根據用戶偏好調整溫度設置。恒溫器使用 M2M 驗證來安全地向中心發送數據并接收命令，確保只有授權的設備可以與家庭的加熱系統互動。

主要摘要#

好的，你已經到達本文的結尾。我能得到一個快速摘要嗎？當然！這裡是重點的快速瀏覽：

1. 範圍： API 金鑰範圍廣泛，PATs（個人訪問權杖）是用戶特定的，M2M（機器對機器）令牌是服務特定的。
2. 壽命： API 金鑰壽命長，PATs 壽命較短，M2M 令牌壽命可變。
3. 表現： API 金鑰是不可見的字符串，PATs 可以是不可見或結構化的，M2M 令牌通常使用 JWT。
4. 用例： API 金鑰用於簡單的 API 訪問，PATs 用於以用戶為中心的操作，而 M2M 令牌用於服務對服務的通信。