繁體中文(香港)
  • api-keys
  • personal-access-tokens
  • machine-to-machine
  • service-to-service
  • backend-to-backend
  • authentication
  • authorization
  • security
  • jwt
  • oauth2
  • rbac

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

探索 API 密鑰、個人訪問權杖 (PAT) 和 Logto 機器到機器 (M2M) 憑證的關鍵概念和常見用例。

Charles
Charles
Developer

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
Product screenshot

背景

在軟件開發中,當我們需要通過 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。請繼續關注我們的功能更新!