前文
本篇主要介紹 postman 的幾種鑒權方式，以及解釋為什么需要鑒權。
鑒權
鑒權就是驗證請求者是否有權從服務器訪問所需要的數據。發送請求時，通常必須包含相應的檢驗參數以確保請求具有訪問權限並返回所需數據。
簡單理解，鑒權就像門禁，你要想進入小區，就得通過門禁卡來驗證身份，這就是鑒權。
官網介紹如下
APIs use authorization to ensure that client requests access data securely.
This can involve authenticating the sender of a request and verifying that they have permission to access or manipulate the relevant data.
If you're building an API, you can choose from a variety of auth models.
If you're integrating a third-party API, the required authorization will be specified by the API provider.
You can pass auth details along with any request you send in Postman.
Auth data can be included in the header, body, or as parameters to a request.
If you enter your auth details in the Authorization tab, Postman will automatically populate the relevant parts of the request for your chosen auth type.
You can use variables and collections to define authorization details more safely and efficiently, letting you reuse the same information in multiple places.
API使用授權來確保客戶端安全地訪問數據。
這可能涉及對請求的發送者進行身份驗證，並驗證他們是否有權訪問或操作相關數據
如果要構建API，則可以從多種身份驗證模型中進行選擇
如果您要集成第三方API，則所需的授權將由API提供程序指定
你能在postman中的任何請求中添加身份詳細信息 Auth數據可以包含在header，body中，也可以作為請求的參數
如果在“Authorization”選項卡中輸入身份驗證詳細信息,postman將自動為您選擇的身份驗證類型填充請求的相關部分
您可以使用變量和集合來更安全，更有效地定義授權詳細信息，從而使您可以在多個位置重復使用相同的信息。
鑒權方式
postman 支持多種鑒權方式，具體如下
- Inherit auth from parent
- No Auth
- API Key
- Bearer Token
- Basic Auth
- Digest Auth
- OAuth 1.0
- OAuth 2.0
接下來，我們分別來看下各種鑒權方式的使用方法
1. Inherit auth from parent
如果將 request 放在集合中，則可以指定身份驗證詳細信息以在整個集合中重復使用。
操作步驟：
點擊集合右邊的擴展 tab（形如...)，打開后，點擊 Edit
此處可以填寫驗證信息
默認情況下，集合下的請求將繼承集合的身份驗證信息，這意味着請求將使用與集合一樣的身份驗證。 要針對單個請求更改此設置，可以在請求的 “Authorization” 選項卡中進行其他選擇。
2. No Auth
如果請求不需要授權即是不需要身份信息，即可選中該選項
3. API Key
使用 API key 身份驗證，可以在請求 header 或參數中將鍵值對發送到 API
也可以直接在 header 中填寫，這樣就不需要在 Authorization 中勾選任何選項
4. Bearer Token
Bearer Token 允許使用訪問密鑰（例如JSON Web Token（JWT））對請求進行身份驗證。token 是文本字符串，包含在請求 header 中。 在 Authorization 中，從類型下拉列表中選擇 Bearer Token。 在令牌字段中，輸入您的API密鑰值-或為了增加安全性，將其存儲在變量中並按名稱引用該變量。
5. Basic Auth
提供用戶名密碼驗證，postman 會自動生成 authorization，當你輸入賬號和密碼后，header 中將向API傳遞一個代表您的用戶名和密碼值的Base64編碼字符串，並附加到文本“ Basic”中，如下所示：
6. Digest Auth
使用 Digest Auth，客戶端發送第一個請求，服務器返回一些數據，包括一個只能使用一次的數字(nonce)、一個realm值和一個401未授權響應。再一次請求時發送一個加密的數據數組，其中包括用戶名和密碼，以及第一次請求中從服務器接收到的數據。服務器使用傳遞的數據生成一個加密的字符串，並將其與您發送的字符串進行比較，以便驗證請求。
通俗的來說就是：Digest Auth 在 Basic Auth 上面擴展了安全性，服務器為每一個連接生成一個唯一的隨機數，客戶端用這個隨機數對密碼進行 MD5 加密，然后返回服務器，服務器也用這個隨機數對密碼進行加密，然后和客戶端傳送過來的加密數據進行比較,如果一致就返回結果。
它是一個二次驗證的過程，會有兩次認證交互消息。
客戶端請求資源->服務器返回認證標示->客戶端發送認證信息->服務器查驗認證。
在1中輸入賬號信息，也是第二次請求傳遞的加密的數據數組
模塊 2 的信息 postman 自動填充，數據來源是第一次請求 service 返回的響應數據。也可以勾選 3 中的勾選框來設置不自動填充
模塊 2 的參數詳細信息：
Realm：由 service 在 WWW-Authenticate 響應頭中指定的字符串。
Nonce: 由服務器在WWW-Authenticate響應頭中指定的唯一字符串。
Algorithm: 一個字符串，指示用於生成摘要和校驗和的一對算法。Postman支持MD5和SHA算法。
qop：應用於郵件的保護質量。 該值必須是服務器在WWW-Authenticate響應標頭中指定的替代值之一。
Nonce Count: 客戶端發送的請求數(包括當前請求)的十六進制計數，該請求中包含nonce值。
Client Nonce: 客戶端提供的一個不透明的帶引號的字符串值，客戶端和服務器都使用它來避免選定的明文攻擊，以提供相互身份驗證，並提供一些消息完整性保護。
Opaque: 服務器在 WWW-Authenticate 響應頭中指定的數據字符串，應該與相同保護空間中的uri一起使用。
7. OAuth 1.0
OAuth 1.0 允許客戶端應用程序訪問第三方 API 提供的數據。例如，作為服務的用戶，您可以授予另一個應用程序訪問該服務的數據的權限，而不必公開您的登錄詳細信息（如QQ，微信登陸）。通過OAuth 1.0 流訪問用戶數據涉及到客戶機應用程序、用戶和服務提供者之間來回的幾個請求。
OAuth 1.0 有時被稱為 “兩條腿” (僅在客戶機和服務器之間進行身份驗證) 或 “三條腿” (客戶機向第三方服務的用戶請求數據)。
OAuth 1.0流的示例如下:
- 為了使用第三方服務請求用戶數據，消費者 (客戶端應用程序) 使用憑證 (如密鑰和 secret )請求訪問令牌。
- 服務提供者發出一個初始令牌 (它不提供對用戶數據的訪問) 和消費者請求用戶的授權。
- 當用戶授予 auth 時，使用者請求將臨時令牌交換為訪問令牌，並通過來自用戶 auth 的驗證。
- 服務提供者返回訪問令牌，然后消費者可以向服務提供者發出訪問用戶數據的請求。
如果在 3 中選擇了 Request Body / Request URL，會發現添加的數據會在請求 body 或者 URL 上顯示，但具體是在哪顯示還要取決於請求的方法。
請求類型是 Post / Put 且 Body 類型是 x-www-form-urlencoded，Postman 將向請求 Body 添加授權參數。請求類型是 Get，則在 URL 上作為參數展示
參數詳解
模塊 1：
Signature Method：API用於驗證請求的方法。
Consumer Key：用於標識服務提供者的使用者的值。
Consumer Secret：使用者用來建立密鑰所有權的值。用於 HMAC 和 PLAINTEXT 簽名方法。
Access Token：表示用戶訪問用戶數據的權限的值
Token Secret：消費者用來建立給定令牌所有權的值。用於 HMAC 和 PLAINTEXT 簽名方法。
Private Key：用於生成認證簽名的私鑰。用於RSA簽名方法。
Advanced Parameters（模塊2）：
Verifier: 用戶認證后，服務提供商提供的驗證碼。
timestamp : 服務器用來防止時間窗口以外的重放攻擊的時間戳。
Nonce：由客戶端生成的隨機字符串
Version：OAuth 鑒權的版本（1.0）
Realm：由服務器在WWW-Authenticate響應頭中指定的字符串。
Encode the parameters in the authorization header ： 參數進行編碼顯示
Advanced Parameters 在使用時不用自己填寫，Postman 會自動幫我們填充
8. OAuth 2.0
OAuth 1.0 允許客戶端應用程序訪問第三方 API 提供的數據。例如，作為服務的用戶，您可以授予另一個應用程序訪問該服務的數據的權限，而不必公開您的登錄詳細信息。對於 OAuth 2.0，首先檢索 API 的訪問令牌，然后使用該令牌對未來的請求進行身份驗證。通過 OAuth 2.0 流訪問數據在 API 服務提供者之間差異很大，但通常涉及到客戶機應用程序、用戶和API之間來回的幾個請求。
OAuth 2.0流的示例如下:
- 客戶端應用程序請求用戶授權對其數據的訪問。
- 如果用戶授予訪問權限，那么應用程序將從服務提供者請求訪問令牌，通過用戶授予的訪問權限和身份驗證詳情來識別客戶端。
- 服務提供者驗證這些細節並返回一個訪問令牌。
- 客戶端使用訪問令牌通過服務提供者請求用戶數據。
在 Authorization 中選擇 OAuth 2.0 tab，如圖：
默認情況下，Postman 將向請求的授權頭中的承載者附加訪問令牌（Access Token 字段），但是如果服務器實現需要不同的前綴，可以在 Header Prefix 字段中指定它。
9. 萬能鑒權
除了上述說的兩種鑒權方式外，還有一種在工作中經常使用的鑒權方式，即將 鑒權信息直接配置在 Headers 域中，其中 Key 即為：Authorization，而值就是我們約定的 token，這種方式經常出現在網關的准入上。
