程序式驗證：API 密鑰、個人存取權杖和 OAuth 客戶端憑證流程

背景#

在軟體開發中，當我們需要通過 CLI 命令程序化訪問 API 資源，或在後端服務之間建立通信時，我們開發者通常使用三種廣泛使用的驗證機制：API 密鑰、個人存取權杖 (PAT) 和 OAuth 客戶端憑證流程（在 Logto 中被命名為 Machine-to-Machine）。但它們之間的區別是什麼？在什麼情況下各種方法最佳？在這篇博客中，我們會深入探討它們的相似之處、區別，並提供在不同情況下使用各種方法的見解。

定義#

• 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 不允許訪問某些服務。例如，向 Azure Artifacts 提供方法發佈 NuGet 包。
• 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 APIs。
• 公共 APIs：當公開 API 時，API 密鑰提供了一種簡單的訪問控制方法。
• 簡化設置：適用於快速及簡單的驗證需求，特別是在開發階段。與 Logto M2M 不同，API 密鑰不需要事先註冊客戶端，也不需要獲得訪問權杖。只需將 API 密鑰作為參數傳遞即可正常運作。

個人存取權杖 (PAT)#

• 用戶特定行為：當應用程序需要以用戶身份執行操作時。
• 精細的用戶訪問控制：當需要對用戶可執行的操作進行精確控制時。

Logto 機器對機器 (Logto M2M)：#

• 安全性：Logto M2M 理想於僅允許信任客戶端提供訪問後端服務的情景。
• 精細的客戶端訪問控制：當需要對應用程序可執行的操作進行精確控制時。

結論#

總之，API 密鑰、PAT 和 Logto M2M 之間的選擇取決於應用程序的具體需求，無論涉及用戶特定行為、機器對機器通信，還是兩者的組合。評估安全和功能需求以確定最合適的驗證方法。

Logto M2M 機制允許用戶設置基於角色控制 (RBAC) 功能的細粒度訪問控制。我們也計劃在不久的將來支持 API 密鑰和 PAT。請密切關注我們的功能更新！