授权设置
很多时候，出于安全考虑我们的接口并不希望对外公开。这个时候就需要使用授权(Authorization)机制授权过程验证您是否具有访问服务器所需数据的权限。当发送请求时，你通常必须包含参数，以确保请求具有访问和返回所需数据的权限。Postman提供授权类型，可以轻松地在Postman本地应用程序中处理身份验证协议。
Postman支持的授权协议类型如下：
No Auth
Bearer Token
Basic auth
Digest Auth
OAuth 1.0
OAuth 2.0
Hawk Authentication
AWS Signature
NTLM Authentication [Beta]Basic auth
基本身份验证是一种比较简单的授权类型，需要经过验证的用户名和密码才能访问数据资源。这就需要我们输入用户名和对应的密码。
案例：请求URL如下，授权账号为：
用户名: postman
密码: password
授权协议为：Basic auth
https://postman-echo.com/basic-auth- 如果不输入用户名密码，直接使用GET请求，则会返回提示：Unauthorized
- 输入用户名密码，选择Basic auth授权类型，则返回如下结果：
{
"authenticated": true
}Digest Auth
Digest auth 是一个简单的认证机制，最初是为HTTP协议开发的，因此也常叫做HTTP摘要。其身份验证机制非常简单，它采用哈希加密方法，以避免用明文传输用户的口令。摘要认证就是要核实參与通信的两方都知道双方共享的一个口令。
当server想要查证用户的身份，它产生一个摘要盘问（digest challenge），并发送给用户。典型的摘要盘问例如以下：
Digest realm="iptel.org", qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="", algorithm=MD5这里包含了一组参数，也要发送给用户。用户使用这些參数，来产生正确的摘要回答，并发送给server。摘要盘问中的各个參数，其意义例如以下：
realm（领域）：领域參数是强制的，在全部的盘问中都必须有。它是目的是鉴别SIP消息中的机密。在SIP实际应用中，它通常设置为SIP代理server所负责的域名。
nonce（现时）：这是由server规定的数据字符串，在server每次产生一个摘要盘问时，这个參数都是不一样的（与前面所产生的不会雷同）。“现时”一般是由一些数据通过md5杂凑运算构造的。
这种数据通常包含时间标识和server的机密短语。这确保每一个“现时”都有一个有限的生命期（也就是过了一些时间后会失效，并且以后再也不会使用），并且是独一无二的
（即不论什么其他的server都不能产生一个同样的“现时”）。
algorithm（算法）：这是用来计算的算法。当前仅仅支持MD5算法。
qop（保护的质量）：这个參数规定server支持哪种保护方案。client能够从列表中选择一个。值auth表示仅仅进行身份查验， auth-int表示进行查验外，另一些完整性保护。
案例：请求URL如下
https://postman-echo.com/digest-auth摘牌配置信息如下：用户名密码和上面basic auth一样
Digest username="postman",
realm="Users",
nonce="ni1LiL0O37PRRhofWdCLmwFsnEtH1lew",
uri="/digest-auth",
response="254679099562cf07df9b6f5d8d15db44",
opaque=""执行请求结果如下：
{
"authenticated": true
}Hawk Auth
Hawk Auth是一个HTTP认证方案，使用MAC(Message Authentication Code，消息认证码算法)算法，它提供了对请求进行部分加密验证的认证HTTP请求的方法。hawk方案要求提供一个共享对称密匙在服务器与客户端之间，通常这个共享的凭证在初始TLS（安全传输层协议）保护阶段建立的，或者是从客户端和服务器都可用的其他一些共享机密信息中获得的。
案例：请求URL如下：
https://postman-echo.com/auth/hawk密钥信息如下：
Hawk Auth ID: dh37fgj492je
Hawk Auth Key: werxhqb98rpaxn39848xrunpaw3489ruxnpa98w4rxn
Algorithm: sha256
执行结果：
{
"message": "Hawk Authentication Successful"
}如果将key改为其他任意的字符则返回如下结果：
{
"statusCode": 401,
"error": "Unauthorized",
"message": "Bad mac",
"attributes": {
"error": "Bad mac"
}
}OAuth 1.0
OAuth（开放授权）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。
扩展资料：
OAuth那些事儿
OAuth的改变
案例：请求URL如下：请求方式为GET，Add authorization data to设置为：Request Headers
https://postman-echo.com/oauth1参数配置为：
Consumer Key: RKCGzna7bv9YD57c
Consumer Secret: D+EdQ-gs$-%@2Nu7
发送请求结果如下：
{
"status": "pass",
"message": "OAuth-1.0a signature verification was successful"
}如果Consumer Secret错误则返回如下结果：
{
"status": "fail",
"message": "HMAC-SHA1 verification failed",
"base_uri": "https://postman-echo.com/oauth1",
"normalized_param_string": "oauth_consumer_key=51zxw&oauth_nonce=pxSgzUivsBi&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1531299384&oauth_version=1.0",
"base_string": "GET&https%3A%2F%2Fpostman-echo.com%2Foauth1&oauth_consumer_key%3D51zxw%26oauth_nonce%3DpxSgzUivsBi%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1531299384%26oauth_version%3D1.0",
"signing_key": "D%2BEdQ-gs%24-%25%402Nu7&"
}Cookie设置
cookie是存储在浏览器中的小片段信息，每次请求后都将其发送回服务器，以便在请求之间存储有用的信息。比如很多网站登录界面都有保留账号密码，以便下次登录。
由于HTTP是一种无状态的协议，服务器单从网络连接上无从知道客户身份。
怎么办呢？就给客户端们颁发一个通行证吧，每人一个，无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理。
Cookie是由服务端生成，存储在响应头中，返回给客户端，客户端会将cookie存储下来，在客户端发送请求时，user-agent会自动获取本地存储的cookie，将cookie信息存储在请求头中，并发送给服务端。postman也可以设置、获取、删除Cookie。
Set Cookies
在Send按钮下方点击Cookies文字菜单，弹出如下界面，然后可以设置Cookie。
请求URL如下：请求方式为GET，添加Cookie值为username:51zxw
http://www.baidu.com/打开Console找到Request Header可以看到自定义设置的Cookie内容。
Get Cookies
Cookie获取比较简单，直接获取Response Headers里面的set-cookie值即可，或者在主界面下方Cookie菜单栏里面也可以查看。
Delete Cookies
点击Cookies文字菜单,然后可以根据需求去清除对应的Cookie。
变量——问题思考
在开发不同阶段可能存在不同的环境,比如测试环境和生产环境。
测试环境API如下：
https://dev.postman.com/get
https://dev.postman.com/post
https://dev.postman.com/put生产环境API如下：
https://postman-echo.com/get
https://postman-echo.com/post
https://postman-echo.com/put在这么情况下，按照常规思路要么你需要维护两套环境的API，要么每次都手动一个个去修改URL，不管哪种选择都比较麻烦且低效，那么有没有比较的好的方法来解决这个问题呢？