Postman 第二讲 Authorization 鉴权
前文
本篇主要介绍 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，这种方式经常出现在网关的准入上。 
