繁體中文（台灣）

api
安全性
身份驗證
PAT
API 金鑰
機器對機器

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

了解個人訪問權杖 (PATs)、機器對機器 (M2M) 驗證和 API 金鑰之間的差異，以及它們的使用方式。

Guamian

Product & Design

7/26/2024

不要在使用者認證上浪費數週時間

使用 Logto 更快地發布安全應用程式。幾分鐘內整合使用者認證，專注於您的核心產品。

立即開始

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

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

相似之處

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

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

Zapier

範例 2：與 Stripe 整合

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

Stripe

個人訪問權杖 (PATs)

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

PATs 如何運作

創建和管理： 用戶通過其帳戶設置在相應平臺上生成 PATs。
- 例如，在 GitHub 中，用戶可以創建具有特定權限和到期日期的精細化或經典 PATs。
- 在如 Jira 和 Confluence 的 Atlassian 產品中，用戶可以從其個人資料設置創建 PATs，指定令牌的名稱和可選的到期時間。
使用： PATs 作為持有者令牌在 API 請求的授權標頭中使用。這意味著它們被包含在 HTTP 標頭中驗證請求。
- 它們允許安全訪問 API 資源，允許用戶根據令牌授予的權限執行諸如創建、閱讀、更新和刪除資源等操作。
- PATs 可以跨平臺內的多個應用使用，提供一種統一的方式來管理訪問和權限。
吊銷和設置到期：
- 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 特別適合開發和自動化用途。

Contentful

範例 2：Airtable

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

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

其系統允許：

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

Airtable

機器對機器 (M2M) 驗證

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

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

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

機器對機器驗證如何運作

它遵循類似的過程：

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

用例

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

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

設置：
- 服務 A 作為客戶端在授權服務器上註冊。
- 為服務 A 提供客戶端 ID 和客戶端密鑰。
驗證：
- 服務 A 向授權服務器請求訪問令牌：
令牌發行：
- 授權服務器驗證憑證並發行 JWT 訪問令牌。
API 請求：
- 服務 A 使用此令牌向服務 B 請求數據：
驗證：
- 服務 B 向授權服務器驗證令牌。
回應：
- 若有效，服務 B 返回請求數據給服務 A。

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

設備對設備通信

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

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

主要摘要

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

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

免費試用 Logto Cloud

相似之處#

差異之處#

API 金鑰#

API 金鑰如何運作？#

用例#

範例 1：與 Zapier 整合#

範例 2：與 Stripe 整合#

個人訪問權杖 (PATs)#

PATs 如何運作#

用例#

範例 1：Contentful#

範例 2：Airtable#

機器對機器 (M2M) 驗證#

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

用例#

主要摘要#