API 授權方法

介紹#

在現今的世界，API 是現代應用程式的支柱。它們是從後端服務獲取數據和功能的主要途徑。API 允許來自不同單位的不同軟體系統相互溝通和共享數據，使其對企業而言不可或缺。然而，API 也是攻擊者的常見目標。API 保護需求比以往任何時候都更強烈。

API 保護是防止未授權訪問、濫用和攻擊的過程。它是所有 API 策略中的關鍵組成部分。在這篇文章中，我們將探討三種常見的 API 保護機制：API 金鑰、基本驗證和 OAuth JWT 令牌。最後，我們也會展示 Logto 如何使用 OAuth JWT 令牌保護你的 API。

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. 使用存取令牌存取受保護的資源。

請查看我們的 機器對機器整合文檔 以獲取更多細節。

Web 應用程式#

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

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

請查看我們的 使用 JWT 和 Logto 保護你的 Express.js API 文章，了解如何將 Logto 與 React 集成並使用 JWT 令牌存取你的 Express 伺服器 API 的全面示例。