繁體中文（香港）

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

個人訪問權杖、機器對機器身份驗證和 API 金鑰定義及其實際案例

學習個人訪問權杖（PATs）、機器對機器（M2M）身份驗證和 API 金鑰之間的差異，以及它們的用法。

Guamian

Product & Design

7/26/2024

Stop wasting weeks on user auth

Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.

Get started

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

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

相似之處

首先讓我們看看這三者之間的相似之處。

安全目的： 所有三種方法均用於保護和控制對 API、服務或資源的訪問。它們都作為身份驗證和/或授權的方式。
基於權杖的方法： 每種方法通常涉及使用唯一的字符串或權杖進行識別。這些權杖通常與 API 請求一起發送，通常在標頭中或作為查詢參數。
可撤銷： 如果被泄露或不再需要時，三種方法中的權杖或金鑰都可以被撤銷或失效。這允許快速的安全響應，而不改變底層系統。
可編程訪問： 所有三種方法都有助於對 API 或服務的程式化訪問。它們使不同系統或應用程序之間的自動化和集成成為可能。
可審核： 這些身份驗證方法的使用可以被記錄和審核。這使得可以跟踪 API 訪問、監控可疑活動和合規報告。
適應訪問控制： 所有三種方法都可以使用具有不同訪問控制和權限的方案。它們可以適應不同的安全模型和架構要求。
協議獨立性： 雖然經常用於 REST API，但這些方法可以應用於各種類型的 API 和協議。

理解這些相似之處有助於識別這些身份驗證方法的共同基礎。它們的差異使得可以根據具體的用例和安全要求選擇最合適的解決方案。

現在，我們來討論它們的差異，專注於它們的用例以及何時使用每種方法。

差異

API 金鑰

API 金鑰用於識別和授權調用的應用程序或服務。它們通常是長壽命的並且在輪換之前是靜態的，通常具有一組固定的權限。它們主要用於服務器對服務器的通信或訪問公共數據，這些權杖通常不代表特定用戶。

API 金鑰如何工作？

API 金鑰由 API 提供者發行並給予註冊的 API 消費者 [1]，API 消費者每个请求都包括这个金鑰。API 伺服器然後檢查 API 金鑰以驗證消費者的身份，才返回請求的數據。

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

[1]: 一個 API 消費者是任何與 API 互動以訪問其功能或數據的應用程序、服務或用戶。他們向 API 發送請求以執行諸如檢索、創建、更新或刪除資源的操作。API 消費者可以是網絡應用程序、移動應用、其他服務器，甚至是利用 API 與其他服務整合或在現有平台之上構建新功能的個別開發者。

Postman: 什麼是 API 金鑰？

使用案例

當人們討論 API 金鑰的使用案例時，他們經常提到自動化、數據共享、測試、開發和安全控制。然而，這些相當技術化。在實際案例中，構建產品時最常見的目的是集成。

例子 1：與 Zapier 的集成

Zapier: 使用 API 金鑰添加身份驗證

Zapier 是一個流行的自動化工具，它連接不同的網絡應用程序。當與 Zapier 集成應用程序時，使用 API 金鑰來驗證和授權訪問該應用程序的 API。例如，想自動化 CRM 系統和電子郵件營銷工具之間的任務，需要從 CRM 系統生成一個 API 金鑰並提供給 Zapier。然後使用該金鑰驗證 Zapier 向 CRM 的 API 發出的請求，讓數據在兩個系統之間安全地流動。

Zapier

例子 2：與 Stripe 的集成

Stripe 利用 API 金鑰來實現與各種平台和應用程序的安全集成。使用開發者儀表板創建、顯示、刪除和滾動 API 金鑰。

Stripe

個人訪問權杖（PATs）

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

PATs 如何工作

創建和管理：用戶通過各平台的賬戶設置生成 PATs。
- 例如，在 GitHub 中，用戶可以創建具有特定權限和到期日期的細粒度或經典 PATs。
- 在 Atlassian 的產品如 Jira 和 Confluence 中，用戶可以從他們的個人資料設置中創建 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 是一個無頭 CMS 平台，提供 PATs 作為使用其內容管理 API (CMA) 的替代 OAuth 權杖。

主要特徵包括：

用戶可以創建多個擁有不同範圍和權限的權杖。
權杖與用戶賬戶綁定，繼承其權限。
PATs 特別適用於開發和自動化目的。

Contentful

例子 2: Airtable

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

Airtable 是一個雲協作平台，實施了 PATs 用於 API 訪問。

他們的系統允許：

創建擁有不同範圍和訪問等級的多個權杖。
權杖可以限制在特定的資料庫或工作區域。
企業管理員可以創建具有更廣泛組織內訪問的權杖。

Airtable

機器對機器 (M2M) 身份驗證

M2M 專為服務對服務的通信而設計，無需人工干預。這源自用戶名和密碼不足以保護服務並且在有效自動化上效率不高的理念。

機器對機器（M2M）應用程序現在採用客戶端憑證流程，這是在 OAuth 2.0 RFC 6749 授權協議 中定義的。它也可以支持類似的標準協議。是的，與 PATs 和 API 金鑰相比，M2M 身份驗證對開放標準更為嚴格。

它驗證的是應用程序或服務本身，而不是用戶，並且通常使用 JWT（JSON Web Tokens）進行無狀態身份驗證。這為服務在分佈式系統中相互互動提供了一種安全方式。

機器對機器身份驗證如何工作

它遵循類似的過程：

客戶憑證： 每個機器（或服務）都有一個唯一的客戶端 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 權杖通常使用 JWTs。
使用案例： API 金鑰用於簡單 API 訪問，PATs 用於用戶中心操作，而 M2M 權杖用於服務對服務的通信。

免費試用 Logto Cloud

相似之處#

差異#

API 金鑰#

API 金鑰如何工作？#

使用案例#

例子 1：與 Zapier 的集成#

例子 2：與 Stripe 的集成#

個人訪問權杖（PATs）#

PATs 如何工作#

使用案例#

例子 1: Contentful#

例子 2: Airtable#

機器對機器 (M2M) 身份驗證#

機器對機器身份驗證如何工作#

使用案例#

主要總結#

相似之處#

差異#

API 金鑰#

API 金鑰如何工作？#

使用案例#

例子 1：與 Zapier 的集成#

例子 2：與 Stripe 的集成#

個人訪問權杖（PATs）#

PATs 如何工作#

使用案例#

例子 1: Contentful#

例子 2: Airtable#

機器對機器 (M2M) 身份驗證#

機器對機器身份驗證如何工作#

使用案例#

主要總結#

相似之處