很多时候，授权是设定好的。出于安全原因，我们的接口不想公开。这时候就需要使用授权机制来验证自己是否有权限访问服务器所需的数据。当发送请求时，通常必须包含参数，以确保请求有访问和返回所需数据的权限。Postman提供授权类型，可以轻松处理Postman本地应用中的认证协议。
Postman支持的许可协议类型如下：
无身份验证无记名令牌基本身份验证摘要身份验证1.0身份验证2.0Hawk身份验证AWS签名身份验证
Basic auth
基本身份验证是一种相对简单的授权类型，它需要经过验证的用户名和密码来访问数据资源。这需要我们输入用户名和相应的密码。
案例：的请求网址如下，授权账号为：
用户名： 邮递员
密码： 密码
授权协议为：基础认证
如果https://postman-echo.com/basic-auth直接使用GET请求而不输入用户名和密码，它将返回提示：未经授权。如果您输入用户名和密码并选择基本身份验证授权类型，将返回以下结果：{ ' authenticated ' 3360 true }Digest Auth
Digest auth是一种简单的身份验证机制，最初是为HTTP协议开发的，因此它通常被称为HTTP digest。其认证机制非常简单，采用哈希加密方式，避免以明文形式传输用户密码。认证是验证参与通信的双方都知道双方共享的密码。
当服务器想要验证用户的身份时，它会生成一个摘要质询并发送给用户。典型的总结性质证如下：
Digestrealm=' iptel.org '，qop=' auth，auth-int '，nonce=' DCD 98 b 7102 D2 f 0 e 8 b 11d 0f 60 BF B0 c 093 '，opaque=' '，算法=MD5。这里包含了一组参数，也应该发送给用户。用户使用这些参数来生成正确的摘要答案，并将其发送到服务器。总结性质证中各参数的含义如下：
realm（领域）：域参数是强制性的，必须包含在所有交叉询问中。它旨在识别SIP消息中的秘密。在SIP的实际应用中，通常设置为SIP代理服务器负责的域名。
nonce（现时）：是服务器指定的数据串，服务器每次生成汇总盘问时这个参数都不一样(不会和上一次一样)。“present”一般由一些数据通过md5哈希运算构造而成。
这种数据通常包含服务器的时间标识和机密短语。这就保证了每个“礼物”都有一个有限的寿命(也就是说，过一段时间就会过期，再也不会被使用)，并且是唯一的。
(即无论其他什么服务器都能产生同样的“礼物”)。
algorithm（算法）：是用于计算的算法。目前仅支持MD5算法。
qop（保护的质量）：的此参数指定服务器支持的保护方案。客户可以从列表中选择一个。值auth表示只进行认证，auth-int表示除了认证之外的一些完整性保护。
案例：请求的网址如下
https://postman-echo.com/digest-auth的退市配置信息如下：用户名和密码与上述基本auth相同。
' Digest username='postman '，realm='Users '，nonce=' ni 1 lil 0 o 37 prrhowdclmwfsneth 1 Lew '，uri='/digest-auth '，response=' 254679099562 cf 07 df 9 b 6 f 5d 8d 15 db 44 '，opaque=' '
d value,normalized response3.jpg">执行请求结果如下：
{ "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/gethttps://dev.postman.com/posthttps://dev.postman.com/put生产环境API如下：
https://postman-echo.com/gethttps://postman-echo.com/posthttps://postman-echo.com/put在这么情况下，按照常规思路要么你需要维护两套环境的API，要么每次都手动一个个去修改URL，不管哪种选择都比较麻烦且低效，那么有没有比较的好的方法来解决这个问题呢？
