程序化身份驗證：API 密鑰、個人訪問權杖和 OAuth 用戶端憑證流程

背景#

在軟件開發中，當我們需要通過 CLI 命令程序化訪問 API 資源，或在後端服務之間建立通信時，通常有三種身份驗證機制被我們開發人員廣泛使用：API 密鑰、個人訪問權杖 (PAT) 及 OAuth 用戶端憑證流程（在 Logto 中被稱為機器到機器）。但它們之間有什麼區別？哪種方法最適合哪種情況？在這篇博客文章中，我們將深入探討它們的相似性、差異性，並提供什麼時候在不同場景中使用每種方法的見解。

定義#

• API 密鑰：可以驗證你對 API 資源請求的簡單字符串。
• 個人訪問權杖 (PAT)：也是一個簡單字符串，但當用於驗證 API 資源時代表一名用戶。它是用戶的委託。
• Logto 機器到機器 (Logto M2M)：一種標準的 OAuth 用戶端憑證流程，要求事先註冊客戶端，並且需要使用客戶端 ID 和密碼來交換訪問權杖。因此，Logto M2M 憑證代表一個受信任的客戶端，並且由於 OAuth 用戶端憑證流程的特性，在使用時相對複雜。

相似性#

1. 驗證目的#

• API 密鑰、PAT 和 Logto M2M 均用於驗證使用者或應用程式以存取特定服務或資源的主要目的。它們充當憑證以證明請求者的身份，通常在 CLI 命令或後端對後端的通信場景中使用。

2. 安全措施#

• 這三種身份驗證方法在處理時都應考慮安全性。開發人員必須確保安全存儲和傳輸，以防止未經授權的存取。

差異性#

1. 用戶上下文#

• API 密鑰不會識別使用者，也不提供任何授權信息。因此，API 密鑰常用於匿名存取公共數據或資源。不是所有服務都支持使用 API 密鑰。
• PAT 是用戶身份，當用於請求 API 資源時將代表你。在某些系統中，PAT 不允許存取某些服務。例如，將 NuGet 套件發佈到 Azure Artifacts 提要中。
• Logto M2M 憑證只能由受信任的客戶端使用。客戶端必須事先註冊，以便被驗證。使用 Logto M2M 憑證時，它代表的是受信任的客戶端，而非使用它的任何用戶。

2. 權限的細化程度#

• PAT 和 Logto M2M 憑證通常比 API 密鑰提供更細化的控制權限，允許對可執行的操作進行精細控制。

3. 權杖格式#

• API 密鑰和 PAT 通常是不透明類型的字符串，簡單明了。
• 通過 Logto M2M 機制發行的訪問權杖通常是 JWT 格式。

4. 授權流程#

• API 密鑰和 PAT 是系統生成的不透明字符串，在過程中不涉及身份驗證流程。比如，你可以這樣調用 Google Cloud 自然語言 API：

• Logto M2M 利用標準的 OAuth 2.0 客戶端憑證流程。每個客戶端必須事先獲取一對客戶端 ID 和客戶端密碼，然後客戶端可以用它們交換訪問權杖。客戶端接著使用該訪問權杖來訪問 API 資源。

什麼時候使用#

API 密鑰#

• 服務到服務的通信：API 密鑰適合應用程序需要通過 CLI 直接與 API 通信的場景。例如，調用 OpenAI API。
• 公共 API：當將 API 暴露給公眾時，API 密鑰提供了一種直接的訪問控制方法。
• 簡化設置：適合快速和簡單的身份驗證需求，尤其是在開發階段。不像 Logto M2M，API 密鑰不需要事先註冊客戶端，也不需要交換訪問權杖。只需在請求中將 API 密鑰作為參數傳遞即可，簡單有效。

個人訪問權杖 (PAT)#

• 用戶特定操作：當應用程序需要代表用戶執行操作時。
• 精細的訪問控制（用戶）：當需要對用戶可執行的操作進行精確控制時。

Logto 機器到機器 (Logto M2M)#

• 安全性：Logto M2M 適合僅允許受信任客戶端存取後端服務的場景。
• 精細的訪問控制（客戶端）：當需要對應用程式可執行的操作進行精確控制時。

結論#

總而言之，選擇 API 密鑰、PAT 或 Logto M2M 取決於應用程序的具體需求，無論涉及用戶特定操作、機器到機器通信或兩者的組合。評估安全性和功能需求，以確定最適合你的用例的身份驗證方法。

Logto M2M 機制允許用戶設置基於 RBAC（角色基於存取控制）功能的細化存取控制。我們也計劃在不久的將來支持 API 密鑰和 PAT。請繼續關注我們的功能更新！