用戶通常需要註冊API密鑰或學習其他方法來驗證請求，然後才能使用您的API發出請求。API驗證用戶身份的方式各不相同。有些API要求您在請求標頭中包含API密鑰，而其他API則需要精心設計的安全性，因為它們需要保護敏感數據，證明身份並確保對請求的篡改。在本部分中，您將瞭解有關身份驗證和授權的更多信息，以及在文檔中應重點關注的內容。

目錄

• 定義術語
• API缺乏安全性的後果
• 不同類型的授權
• API密鑰基本認證HMAC（基於哈希的消息授權碼）OAuth 2.0
• 文檔化授權
• 授權部分示例
• 活動：授權分析

定義術語

首先，讓我們定義一些關鍵術語：

• 身份驗證：指證明正確的身份
• 授權：指允許某個動作

API可能會對您進行身份驗證，但未授權您發出特定請求。

API缺乏安全性的後果

為什麼API甚至需要身份驗證？對於只讀API，有時用戶不需要密鑰。但是大多數商業API確實需要以API密鑰或其他方法的形式進行授權。如果您的API沒有任何安全性，則用戶無需進行任何註冊即可無限次數地調用API。允許無限制的請求將使您的API的收入模型變得困難。

此外，如果沒有身份驗證，就沒有一種將請求與特定用戶數據相關聯的簡便方法。而且，還沒有一種方法可以防止惡意用戶的請求刪除惡意用戶的請求（例如，通過對另一個帳戶進行DELETE請求）。

最後，您無法跟蹤誰在使用您的API或最常使用哪些端點。顯然，API開發人員必須考慮驗證和授權對其API的請求的方法。總體而言，使用API​​進行身份驗證和授權具有以下目的：

• 僅向註冊用戶驗證對API的調用
• 跟蹤誰在發出請求
• 跟蹤API的使用
• 阻止或限制超出速率限制的任何請求者
• 將不同的權限級別應用於不同的用戶

以下是您可能會遇到的各種API授權：

• API keys
• Basic Auth
• HMAC
• OAuth

API Key

大多數API都要求您註冊一個API密鑰才能使用該API。API密鑰是一個長字符串，通常包含在請求URL或請求標頭中。API密鑰主要用作識別進行API調用的人員的方式（驗證您使用該API的身份）。API密鑰也可能與您註冊的特定應用程序相關聯。

APK Key在標頭屬性中使用字符串來授權請求

API可能會同時為您提供公鑰和私鑰。公鑰通常包含在請求中，而私鑰則更像是密碼，僅在服務器到服務器的通信中使用。對於某些API文檔網站，當您登錄該網站時，您的API密鑰會自動填充到示例代碼和API資源管理器中。

Basic Auth

另一種授權類型稱為基本身份驗證。使用此方法，發送方將username：password放入請求標頭中。用戶名和密碼使用Base64編碼，Base64是一種編碼技術，可將用戶名和密碼轉換為一組64個字符，以確保安全傳輸。這是請求標頭中的基本身份驗證的示例：

<code>Authorization: Basic bG9sOnNlY3VyZQ==/<code>

使用基本身份驗證的API也將使用HTTPS，這意味著消息內容將在HTTP傳輸協議內進行加密。（沒有HTTPS，人們可以很容易地解碼用戶名和密碼。）

當API服務器收到消息時，它將解密消息並檢查標頭。在對字符串進行解碼並分析了用戶名和密碼之後，它將決定是接受還是拒絕請求。

在Postman中，可以通過以下方式配置基本授權：單擊“授權”選項卡，從下拉選擇器中選擇“基本驗證”，然後在冒號右側的每一行上鍵入用戶名和密碼。標頭選項卡將顯示一個鍵值對，如下所示：

<code>Authorization: Basic RnJlZDpteXBhc3N3b3Jk/<code>

當您輸入用戶名和密碼並選擇基本身份驗證時，Postman會自動為您處理Base64編碼。

HMAC代表基於哈希的消息授權代碼，是一種更強大的身份驗證類型，在金融API中更為常見。使用HMAC，發送者和接收者都知道一個別人沒有的秘密密鑰。發件人基於某些系統屬性（例如，請求時間戳和帳戶ID）創建一條消息。

然後，該消息由secret密鑰編碼，並通過安全哈希算法（SHA）傳遞。（哈希是基於算法的字符串加擾。）結果值（稱為簽名）被放置在請求標頭中。

當接收方（API服務器）接收到請求時，它將採用相同的系統屬性（請求時間戳和帳戶ID），並使用密鑰（只有請求者和API服務器才知道）和SHA生成相同的字符串。如果字符串與請求標頭中的簽名匹配，則它接受請求。如果字符串不匹配，則請求被拒絕。

這是描述此工作流程的圖：

HMAC工作流程

重要的是，私有密鑰（對於重建哈希至關重要）僅對發送者和接收者而言是已知的。密鑰不包含在請求中。當您要確保請求既真實又未被篡改時，可以使用HMAC安全性。

OAuth 2.0

OAuth 2.0是一種用於驗證和授權用戶的流行方法。此方法依賴於身份驗證服務器與API服務器進行通信以授予訪問權限。使用網站時，您通常會看到OAuth 2.0，並被提示使用Twitter，Google或Facebook之類的服務登錄。

OAuth登錄窗口

OAuth有幾種變體，即“one-legged OAuth”和“three legged OAuth”。如果您沒有敏感數據需要保護，則使用one-legged OAuth。如果您只是在獲取常規的只讀信息，則可能是這種情況。相反，當您需要保護敏感數據時，使用thress-legger OAuth。在這種情況下，有三個組進行交互：

• 認證服務器
• 資源服務器（API服務器）
• 用戶或應用

這是OAuth 2.0的基本工作流程：

OAuth驗證

首先，消費者應用程序將應用程序密鑰和機密發送到身份驗證服務器上的登錄頁面。如果通過了身份驗證，則身份驗證服務器將使用訪問令牌響應用戶。

將該訪問令牌打包到對請求的響應重定向（302）中的查詢參數中。重定向將用戶的請求指向資源服務器（API服務器）。

然後，用戶向資源服務器（API服務器）發出請求。將訪問令牌添加到API請求的標頭中，其單詞為Bearer，後跟令牌字符串。API服務器會檢查用戶請求中的訪問令牌，並決定是否對用戶進行身份驗證。

訪問令牌不僅為請求者提供身份驗證，而且還定義了用戶如何使用API​​的權限。此外，訪問令牌通常會在一段時間後過期，並要求用戶再次登錄。有關OAuth 2.0的更多信息，請參閱以下資源：

• Learn API Technical Writing 2: REST for Writers (Udemy), by Peter Gruenbaum
• OAuth simplified, by Aaron Parecki

文檔化認證

在API文檔中，您無需向外部用戶詳細說明身份驗證的工作原理。實際上，不解釋身份驗證過程的內部細節可能是最佳實踐，因為這會使黑客更難濫用API。

但是，您確實需要解釋一些必要的信息，例如：

• 如何獲取API密鑰
• 如何驗證請求
• 與無效身份驗證有關的錯誤消息
• 身份驗證信息的敏感性
• 令牌到期時間

如果您有公共密鑰和私有密鑰，則應解釋每個密鑰的使用位置，並注意不要共享私有密鑰。如果不同的許可證層為API調用提供了不同的訪問權限，則這些許可證層應在您的授權部分或其他地方明確顯示。

由於在開發人員開始使用API​​之前，API密鑰部分通常是必不可少的，因此該部分需要出現在幫助的開頭。

以下是API文檔中授權部分的一些示例。

SendGrid

SendGrid API keys

SendGrid提供API密鑰的詳細說明，從基礎知識開始，解釋“什麼是API密鑰？”。在上下文中，API密鑰主題與其他帳戶管理主題一起出現。

Twitter

Twitter authorization

使用Twitter，因為涉及到OAuth 2.0授權要求，所以需要提供並提供詳細的示例。

Amazon Web Services

Amazon authorization

Amazon示例使用HMAC。該過程非常複雜，因此其中包含完整的圖表以顯示用戶需要執行的步驟。

‌Dropbox

Dropbox authorization

像Twitter一樣，Dropbox也使用OAuth 2.0。他們的文檔不僅包括一個圖，還包括兩個圖以及對該過程的擴展說明。

‌

使用您確定的開源項目，標識有關對API請求的授權的信息。回答以下問題：

1. 向API發出請求需要哪種授權？
2. 授權中是否有不同的訪問級別（例如，免費與專業級）來確定您可以發出多少個請求或可以訪問的信息類型？
3. 您是否可以獲取API密鑰或對API進行測試調用所需的任何授權方法？
4. 如何將有關授權的信息整合到入門教程中？

閱讀更多 沙場點兵見穹蒼 的文章

關鍵字: 算法 BASIC語言 身份驗證