API 授權方法

簡介#

在當今世界，API 是現代應用程式的支柱。它們是從後端服務訪問數據和功能的主要方式。API 允許不同合作方的不同軟件系統進行通信和數據共享，使其對於企業來說必不可少。然而，API 也是攻擊者常見的目標。對 API 保護的需求比以往更強烈。

API 保護是指保護 API 免受未經授權的訪問、濫用和攻擊的過程。這是任何 API 策略的一個關鍵組成部分。在這篇文章中，我們將探討三種常見的 API 保護機制：API 金鑰、基本認證和 OAuth JWT 令牌。最後，我們還將展示 Logto 如何使用 OAuth JWT 令牌來保護你的 API。

API 金鑰#

API 金鑰是最簡單和廣泛使用的方法來保護 API。API 提供者生成一串長的字符，並與授權用戶共享。這個金鑰需要包含在請求標頭中才能訪問 API。API 金鑰對於基本的安全需求來說簡單而有效。例如，像 Google Maps API 和 AWS 這樣的熱門服務提供 API 金鑰來控制訪問和監控使用情況。然而，在安全性方面它們有局限性。它們通常用於機器對機器的通信。

例如：

優點：#

• 實施簡單：API 金鑰易於實施和使用。它們涉及將金鑰附加到請求標頭，這對於開發人員和客戶端來說都是一個簡單而直觀的方法。
• 易於監控：API 金鑰易於監控。你可以跟踪每個金鑰的使用情況，並在必要時撤銷它們。
• 有效的速率限制：API 金鑰在速率限制方面有效。你可以為每個金鑰設置請求數量的限制，以防止濫用。
• 適合非敏感數據：API 金鑰適合非敏感數據或公開可用的 API，其中安全要求較低。

缺點：#

• 安全性有限：API 金鑰對於敏感數據來說不夠安全，尤其是對於客戶端應用程式。它們通常用於機器對機器的通信。
• 不適用於用戶認證：API 金鑰與應用程式或系統綁定，而非個別用戶，因此難以識別具體用戶或追蹤他們的操作。
• 沒有令牌到期：API 金鑰通常是靜態的且不會過期。如果金鑰被洩露，則可被無限期濫用，除非手動重新生成。

基本認證#

基本認證是另一種常見的 API 保護方法。它是一種內置於 HTTPs 協議中的簡單的認證方案。它涉及在請求標頭中發送用戶名和密碼。伺服器然後驗證憑證，如果有效，則返回請求的資源。例如，許多 Web 應用程式和 RESTful API 使用基本認證作為用戶認證的快速和簡單方法。基本認證比 API 金鑰更安全，因為它使用用戶名和密碼而不是靜態金鑰。但是，對於敏感數據來說，它仍然不夠安全。由於客戶端憑證以明文傳輸，因此容易被攔截。基本認證適用於內部系統，其中網絡連接是安全的，例如機器對機器的通信。

例如：

或

優點：#

• 更強的安全性：基本認證比 API 金鑰更安全，因為它使用用戶名和密碼而非靜態金鑰。
• 廣泛支持：基本認證被大多數 Web 伺服器和瀏覽器廣泛採用和支持。
• 簡易性：像 API 金鑰一樣，基本認證相對簡單易於設置和使用。

缺點：#

• 憑證暴露：基本認證以明文傳輸憑證，如果未使用安全連接（HTTPS），則容易被攔截。
• 沒有令牌到期：基本認證不支持令牌到期。如果令牌被洩露，則可能被無限期濫用，除非手動重新生成。

OAuth JWT 令牌#

JSON Web Token（JWT），由 RFC 7519 定義，是一種安全地在合作方之間以 JSON 對象形式傳輸信息的開放標準。它通常用於 Web 應用程式和 API 的身份驗證和授權。

一個簽名的 JWT 具有以下格式：

它由用 . 分隔的三部分組成：標頭、有效負載和簽名。

以下是一個 JWT 的例子：

• 標頭：包含有關令牌類型和用於簽名的哈希算法的信息。
• 有效負載：包含有關用戶的聲明（聲明）和其他數據。
• 簽名：是使用密鑰簽名的標頭和有效負載的哈希值。

OAuth 是一個全面的保護 API 的開放標準，常用作客戶端用戶授予網站或應用程式訪問其在其他網站上的信息而不提供密碼的一種方式。

當與 JWT 一起使用時，OAuth JWT 令牌提供了一種強大的安全解決方案。OAuth JWT 令牌發放給成功身份驗證的授權客戶端，這些令牌包含有關用戶和其权限的信息。此外，JWT 令牌被數字簽名以防篡改，並且可以過期，提供額外的安全層。

OAuth JWT 令牌的一個關鍵優勢是其靈活性。它們可以用於各種類型的應用程式，包括 Web 和移動應用程式、單點登錄解決方案等。例如，主要社交媒體平台如 Facebook、Twitter 和 LinkedIn 使用 OAuth JWT 令牌來驗證用戶並使第三方應用程式安全地訪問用戶數據。

優點：#

• 增強的安全性：OAuth JWT 令牌提供更高層次的安全性。它們被數字簽名並可以加密，減少未經授權訪問和數據篡改的風險。
• 用戶身份和訪問控制：JWT 令牌可以攜帶用戶身份信息，並包含指定用戶授權訪問哪些操作或資源的聲明。
• 精細化訪問控制：JWT 令牌可以用於實施精細化訪問控制。例如，你可以指定用戶可以訪問哪些資源，並可以在這些資源上執行哪些操作。
• 令牌到期：OAuth JWT 令牌可以設置在一定時間後過期，減少被濫用的風險。

缺點：#

• 複雜性：OAuth JWT 令牌比 API 金鑰和基本認證更複雜。它們需要額外的步驟來設置和使用。
• 令牌管理：OAuth JWT 令牌需要管理和在必要時撤銷。這對於有大量用戶和客戶端的大型應用程式來說可能有挑戰性。
• 資源消耗：生成和驗證令牌可能會有一些性能開銷，這可能在高流量場景中需要關注。

Logto API 保護#

認證方法的選擇取決於你的應用程式的具體要求和安全考慮。API 金鑰簡單但不太安全，基本認證提供更多安全性，但缺乏用戶身份功能，而 OAuth JWT 令牌提供強大的安全性和用戶身份功能，但增加了實施和管理的複雜性。

Logto 提供了一種簡單而安全的方法來使用 OAuth JWT 令牌保護你的 API。它支持 OAuth 2.0 和 OpenID Connect (OIDC) 標準，允許你選擇最適合你需要的認證方法。你可以使用 client_credentials 流來進行機器對機器的通信，authorization_code 流來進行 Web 應用程式。

機器對機器通信#

Logto 使用 client_credentials 流來適用於機器對機器類型的應用程式。這個流適用於後端服務器通信，其中客戶端是一個可以安全存儲客戶端憑證的機密客戶端。它也被稱為 "雙向 OAuth"，因為它不涉及用戶。客戶端憑證直接用作獲取訪問令牌的授權授予。

整合流程簡單且直接：

1. 在 Logto 控制台中創建一個 API 資源。
2. 在 Logto 控制台中創建一個機器對機器的客戶端。
3. 發送請求到 Logto 令牌端點以獲得訪問令牌。

4. 使用訪問令牌訪問受保護的資源。

請查看我們的 machine-to-machine integration documentation 獲取更多詳情。

Web 應用程式#

對於像 Web 應用程式這樣的公共客戶端，Logto 使用 authorization_code 流來認證用戶。這個流適用於公共客戶端無法安全存儲客戶端憑證的 Web 應用程式。它也被稱為 "三向 OAuth"，因為它涉及用戶。用戶被重定向到授權伺服器以進行身份驗證和授權客戶端。然後客戶端使用授權碼來獲取訪問令牌。

整合流程比機器對機器的流程稍微複雜一些：

請查看我們的 Protect your Express.js API with JWT and Logto 文章作為將 Logto 與 React 整合和使用 JWT 令牌訪問你的 Express 伺服器 API 的全面示例。