【Authorization】(API测试)HTTP请求头Authorization几种类型分析使用

【Authorization】API测试，HTTP请求头Authorization几种类型分析使用

在这里插入图片描述

一、Authorization

1. Authorization是什么？

Authorization是HTTP 提供一个用于权限控制和认证的通用框架，可能感到疑惑"Cookie不就可以做权限控制和认证吗？ "， Cookie确实是在单个系统内认证用户身份、保持会话状态的有效方式，但如果涉及到多个系统、多个域名或多个应用程序之间认证、授权呢？使用Cookie的话该如何办呢？为解决这个问题， HTTP急需一种更通用、更灵活的身份验证和授权机制，使跨系统和跨域的身份验证和授权管理更容易，这对于现代应用程序中的多样化环境非常重要，就这样Authorization诞生了！

Authorization是一种通用的、标准化的权限控制和认证的通用框架，它能够使跨系统和跨域的身份验证和授权管理更容易，使不同应用程序之间能够更轻松地实现单点登录（SSO）、用户身份验证和授权控制等。

Postman或者ApiFox中一共拥有十种Authorization类型。以下是Postman官网提供的原话：Authorization是验证是否拥有从服务器访问所需数据的权限。当发送请求时，通常必须包含参数，以确保请求具有访问和返回所需数据的权限。

2.Authorization运行方式

Authorization仅是一个通用的认证框架，它并没有强制规定具体的使用方式，而是只提供了一种结构化的方式来管理身份验证和访问控制。它具体的身份验证方案和授权流程可以根据不同的需求和协议而有所不同，但大体的流程都如下图所示：在这里插入图片描述

(1) 客户端请求授权：客户端请求获得访问资源的授权，通常请求授权可以是账户密码登录/私秘钥等。
(2) 服务端返回授权码/令牌：服务器收到客户端的授权请求后会验证其身份的有效性，如果有效则会给相应用户授权，并发送相应的授权码或令牌。
(3) 客户端携带令牌请求内容：客户端在请求头Authorization中携带服务器返回的授权码/令牌发起请求。
(4) 服务端携验证令牌：资源服务器接收到客户端请求，验证令牌的有效性和权限。这可能涉及验证签名、检查令牌的有效期和授权范围等。如果令牌有效且授权被授予，资源服务器允许客户端访问受保护的资源。

无论是存放服务端返回的令牌或授权码，还是给请求头Authorization携带令牌，都需要客户端自行使用代码处理，浏览器并不会与处理Cookie一样自动保存/携带Authorization。

二、Authorization类型详解

1. Inherit auth from parent （从父类继承）

可向集合（collection）或者文件夹（folder）添加授权。

下面举一个简单的案例来说明下用法：

假设现在有这样的一个集合，它的授权方式是"No Auth"（不使用任何授权），我们在集合下面添加一个文件夹并将此文件夹的默认授权方式更改为"Inherit auth from parent"，那么此文件夹下的所有请求将使用父类的授权类型，即集合的授权类型——“No Auth”;

2. No Auth

当不需要授权参数发送请求时，使用"No Auth"。

3. Bearer Token (安全令牌)

Bearer认证方案是在 RFC 6750 中规定的，它是一种用于HTTP的认证方案，也被称为Token(令牌)认证，它是基于OAuth2.0认证协议的认证方案。

该方案使用令牌(token)授权，令牌(token)就像你持有的一张人民币一样，只要你持有它，你就可以使用它，而不像银行卡需要输入账户密码，正因这个特性，它被广泛使用于跨系统和跨域的身份验证和授权中。

Bearer Token是安全令牌。任何带有Bearer Token的用户都可以使用它来访问数据资源，而无需使用加密密钥。

使用Bearer Token认证过程:
在这里插入图片描述

客户端发送一个请求到服务器。
如果服务器需要请求第三方服务器资源，并且需要认证，此时它会返回一个401未授权的响应，同时返回一个第三方服务认证授权的地址。
客户端收到相应后会重定向到第三方服务认证授权的地址，待用户填写相应信息确认授权后，授权请求发送到第三方服务器。
第三方服务器收到授权请求后，判断认证信息是否正确，如果认证信息正确，服务器会生成一个Bearer令牌，并将其发送回客户端。这个令牌是一个长字符串，它代表了用户的身份。
客户端收到响应后，将令牌取出并存储起来，通常是在本地存储或者cookie中，存储过程需要开发人员自行操作。
客户端携带令牌Authorization: Bearer <token>，再次发出请求，携带令牌需要开发人员自行操作。
服务器收到令牌后会使用该令牌向第三方服务器继续请求资源。
第三方服务器收到请求后，会判断令牌是否有效，如果令牌验证成功，服务器就会处理请求并返回响应。

Bearer认证需注意令牌防盗
由于Bearer令牌可以被任何人使用，所以一旦令牌被盗用，资源就受到威胁。因此，必须采用适当的安全措施。如：使用Https加密通信，或者定期刷新令牌等手段。

4. API Key

API密钥认证（API Key Authentication）是一种用于保护和控制对Web服务或API资源的访问的常见方式。它基于在每个请求中包含一个唯一的API密钥，以便服务器可以验证请求的合法性。这种认证方式通常用于对第三方开发者、应用程序或用户授予对API的有限访问权限。

API密钥认证流程：
在这里插入图片描述

生成API密钥：API提供者会生成一个唯一的API密钥，并将其分发给授权的开发者或应用程序.
包含API密钥：在进行API请求时，开发者或应用程序需要在请求中包含他们的API密钥。这通常是通过在HTTP请求的头部、查询参数或请求体中添加密钥来实现的。
服务器验证：API服务器收到请求后，会提取其中的API密钥，并与存储的有效密钥进行比对。如果密钥有效且请求符合授权要求，服务器将允许请求继续处理；否则，服务器将返回相应的错误信息。
访问控制：一旦API密钥被验证通过，服务器可以根据密钥对应的权限级别，控制对API资源的访问权限。这可以包括限制每个密钥的请求速率、限制对特定资源的访问等。

5. JWT

JWT(JSON Web Token)认证与Bearer认证的原理是一样的，并且其运行流程也并无差异。

他们的关键差别仅在于：

令牌类型：
- Bearer认证使用的令牌通常是一个随机生成的字符串，它本身不包含任何用户信息。
- 而JWT是一种特殊的令牌，它是一个编码后的JSON对象，可以包含一些用户信息和其他元数据。
状态：
- Bearer认证通常是状态性的，这意味着服务器需要存储令牌信息以便验证。
- 而JWT是无状态的，因为JWT本身就包含了所有需要验证的信息，服务器不需要存储任何关于JWT的信息。
使用方式：在使用方式上，JWT和Bearer认证都很相似。它们都是在HTTP请求的头部字段中发送的，格式通常是Authorization: Bearer <token>。这里的可以是一个Bearer令牌，也可以是一个JWT。
安全性：JWT可以使用数字签名或者加密来保证其安全性。而Bearer令牌的安全性主要依赖于HTTPS来防止令牌在传输过程中被窃取。

6. Basic Auth (基本身份认证)

Basic认证方案是在 RFC 7617 中规定的，被称为基本身份认证，是一种用于HTTP的简单认证方案。该方案通过在HTTP请求中发送用户名和密码来进行身份验证。

基本身份验证是一种比较简单的授权类型，需要经过验证的用户名和密码才能访问数据资源。这就需要我们输入用户名和对应的密码。

Basic auth认证流程：
在这里插入图片描述

客户端发送一个请求到服务器。
如果服务器需要认证，它会返回一个401未授权的响应，同时在响应头中包含一个WWW-Authenticate字段，该字段值为Basic realm="xxx"，Basic表明请求该资源需要进行Basic认证，其中"xxx"是服务器对资源的描述。
客户端在接收到401响应后，会提示用户输入用户名和密码。然后，客户端将用户名和密码拼接成一个字符串，格式为"username"，并对这个字符串进行Base64编码。
客户端再次发送相同的请求，但这次在请求头中包含一个Authorization字段，该字段值为Basic后接上一步得到的Base64编码字符串。
服务器接收到请求后，解码Authorization字段的值，验证用户名和密码。如果验证通过，服务器就会处理请求并返回响应。如果验证失败，服务器会再次返回401响应。

Basic其实并不安全，因为它只是简单的对用户名和密码进行Base64编码，Base64是轻易被解码的，由于"Basic auth"使用明文传递，目前基本很少使用了。除非使用https等方式对通信进行加密传输。不应该在高安全场合使用Basic auth。

7. Digest Auth (摘要认证)

Digest认证方案是在 RFC 7616 中规定的，它是一种用于HTTP的认证方案，也被称为摘要认证，是基本认证（Basic Authentication）的一个改进版本，它提供了比基本认证更好的安全性。

在"Digest Auth"流程中，客户端向服务器发送请求，服务器返回客户端的nonce和realm值；客户端对用户名、密码、nonce值、HTTP请求方法、被请求资源URI等组合后进行MD5运算，把计算得到的摘要信息发送给服务端。服务器然后发回客户端请求的数据。通过哈希算法对通信双方身份的认证十分常见，它的好处就是不必把具备密码的信息对外传输，只需将这些密码信息加入一个对方给定的随机值计算哈希值，最后将哈希值传给对方，对方就可以认证你的身份。Digest思想同样采如此，用了一种nonce随机数字符串，双方约好对哪些信息进行哈希运算即可完成双方身份的验证。Digest模式避免了密码在网络上明文传输，提高了安全性，但它仍然存在缺点，例如认证报文被攻击者拦截到，攻击者可以获取到资源。

Digest Auth认证流程：
在这里插入图片描述

客户端发送一个请求到服务器。
如果服务器需要认证，它会返回一个401未授权的响应，同时在响应头中包含一个WWW-Authenticate字段，该字段值包含了认证方式（Digest）、一个随机生成的nonce值(nonce)、域名（realm）等信息。
客户端在接收到401响应后，会提示用户输入用户名和密码。待用户输入完成，客户端会使用服务器返回的nonce值、URL与用户名、密码相结合然后通过 MD5 加密生成哈希密钥也叫响应(response)值。
客户端再次发送相同的请求，但这次在请求头中包含一个Authorization字段，该字段值包含了认证方法(Digest)、用户名(username)、域名(realm)、nonce值(nonce)、响应值(responese)等信息。
服务器收到请求后，可以使用username查询到相应用户的密码，然后使用同样的方式生成响应值，最后与客户端的响应值比对，如果服务器的响应值与客户端的响应值一致，服务器就会处理请求并返回响应。

摘要认证的安全性比基本认证高，因为基本认证仅对传输的用户名、密码进了Basic64编码，相当于是以明文形式发送用户名和密码，而摘要认证向客户端提供了一次性使用编号（nonce），该编号与用户名、密码和 URL相结合并通过 MD5 加密生成哈希密钥（response 响应值），传输过程也是传输的哈希密钥，因此即使攻击者截获了认证信息，他们也无法直接得到用户的密码。

8. OAuth 1.0

OAuth 1.0是一种可以让我们在不公开密码的情况下授权使用其他应用程序的授权模式。

流程：OAuth 1.0 使用了一个三步的认证流程，包括请求令牌和访问令牌。首先，客户端向授权服务器请求一个未授权的请求令牌（Request Token）。然后，用户授权后，客户端使用授权的请求令牌换取访问令牌（Access Token）。最后，客户端使用访问令牌访问受保护的资源。

特点：每个令牌都有一个对应的密钥（secret），增加了安全性。但是，它使用 HTTP 协议，存在被劫持攻击的风险。

在Postman中按照以下步骤使用OAuth 1.0授权：

在Authorization下来授权标签中选择“OAuth 1.0”授权模式；
在“Add authorization data to” 下拉选择框中，选择对应的请求模式。
当选择“Request Body/Request URL”时，Postman将检查请求方法是POST还是PUT，以及请求主体类型是否是x-www-form-urlencoded；如果是这样，Postman将增加授权参数到请求主体。对于所有其他情况，它会向URL添加授权参数。

9. OAuth 2.0

OAuth 2.0作为OAuth 1.0的升级版本。

流程：OAuth 2.0 简化了认证流程，主要包括四种授权模式：授权码模式（Authorization Code）、简化模式（Implicit）、密码模式（Resource Owner Password Credentials）和客户端模式（Client Credentials）。

最常用的是授权码模式，它包括三个步骤：客户端引导用户到授权服务器请求授权，用户授权后返回授权码，客户端使用授权码换取访问令牌，最后使用访问令牌访问资源。

特点：OAuth 2.0 去掉了签名，改用 SSL（HTTPS）确保安全性。所有的令牌不再有对应的密钥，签名过程更简洁。它支持多种客户端类型，包括基于浏览器的应用和移动应用。OAuth 2.0 的访问令牌是短命的，并且有刷新令牌（Refresh Token）机制，以延长访问权限。

在Postman中按照以下步骤进行使用：

在Authorization下来授权标签中选择“OAuth 2.0”授权模式；
在“Add authorization data to”下拉选择框中，选择对应的请求模式；
设置请求的授权参数，有以下三个选择：
点击“Get New Access Token”按钮，在弹出的对话框中输入对应的参数；单击“Request Token”按钮获取对应的Token。接下来有了对应的Token后，就可以点击“Send”按钮发送请求了；
在“Access Token”输入框中输入一个Token，或者Token对应的环境变量，然后就可以点击“Send”按钮发送请求了；
在“Available Tokens”下拉框中选择已经存在的Token，然后发送请求。

10. Hawk Authentication

hawk是一个HTTP认证方案，使用MAC(Message Authentication Code，消息认证码算法)算法，它提供了对请求进行部分加密验证的认证HTTP请求的方法，包括HTTP方法、请求URI和主机。

hawk方案要求提供一个共享对称密匙在服务器与客户端之间，通常这个共享的凭证在初始TLS保护阶段建立的，或者是从客户端和服务器都可用的其他一些共享机密信息中获得的。

11. 2FA（双因素认证）

双因素认证（Two-Factor Authentication, 2FA）是一种身份验证方式，要求用户在登录时提供两种不同类型的身份验证信息，通常是"Something you know"（你所知道的）和"Something you have"（你所拥有的）。这种方式比单一密码更安全，因为即使密码泄露，仍需要第二种身份验证信息才能完成登录。

双因素认证流程：
在这里插入图片描述

用户尝试登录：用户在登录时输入其用户名和密码。
第一因素验证：系统验证用户名和密码的正确性。
第二因素验证：如果第一因素验证通过，系统会要求用户提供第二种身份验证信息。这通常是通过手机短信、手机应用程序生成的动态验证码、硬件安全密钥（如YubiKey）或生物识别信息（如指纹或面部识别）来实现的。
访问控制：一旦第二因素验证成功，用户将被授予访问权限。

12.其他一些认证方式

（1） AWS Signature（AWS签名验证）:

流程：AWS签名验证是亚马逊网络服务（AWS）用来确保请求的安全性和发送者身份的一种机制。通常涉及到使用AWS提供的密钥对请求进行签名。这个过程包括生成一个签名版本，该版本是使用用户的私钥对请求参数进行加密得到的。
特点：安全性高，可以防止请求被篡改。适用于AWS服务的API调用，确保数据传输的安全性。

（2） Kerberos:

流程：Kerberos是一种网络认证协议，它使用票据来验证用户的身份。用户首先向Kerberos服务器请求一个票据授予票据（TGT），然后使用这个TGT向目标服务请求服务票据（ST）。服务票据用于访问特定的服务。
特点：提供了强认证，并且可以防止窃听和重放攻击。它依赖于一个可信的第三方（Kerberos服务器）来分发票据。

（3）NTLM Authentication（NT LAN Manager 认证）:

流程：NTLM是一种挑战-响应认证机制，用于Windows操作系统。当用户尝试登录时，系统会生成一个随机的挑战（一个64位的数），用户密码的哈希值与这个挑战结合后再次哈希，结果发送回服务器。服务器使用存储的密码哈希和挑战来验证响应。
特点：设计用于在不安全的网络中提供认证，但相比Kerberos，它被认为是不够安全的，因为它的加密强度较低。

（4） Akamai EdgeGrid:

流程：Akamai EdgeGrid是一个提供API网关、访问管理和其他安全功能的平台。它允许用户通过API与Akamai的CDN服务进行交互。认证通常涉及到使用API密钥和令牌，这些密钥和令牌用于签署和验证请求。
特点：提供了细粒度的访问控制和安全策略，可以与Akamai的内容分发网络（CDN）紧密集成，以提高性能和安全性。

三、WWW-Authenticate响应标头以及 Authorization请求标头

WWW-Authenticate响应标头

响应标头WWW-Authenticate 定义了获取特定资源的访问权限的认证方法。服务器将以 401 Unauthorized去响应访问受保护资源的请求，该响应必须包含至少一个 WWW-Authenticate 标头和一个质询，以指示客户端使用哪些身份验证方案访问资源（以及每个特定方案的任意额外的数据）。一个 WWW-Authenticate 标头中允许多个质询，并且一个响应中允许多个 WWW-Authenticate 标头。

参数

<auth-scheme>
用于指定访问该资源需要进行的身份验证方案。一些更常见的身份验证方案是（不区分大小写）：Basic、Digest、Negotiate 和 AWS4-HMAC-SHA256。
realm=“<string>” 可选
用于指定一段描述信息

除了上述的参数外，该标头对于不同的身份验证方案也有一些不同的参数：

Basic认证

charset=“UTF-8” 可选
当提交用户名和密码时，告诉客户端服务器的首选编码方案，仅允许值“UTF-8”。

Digest认证

domain=“<URI> <URI> <URI>…” 可选
以空格分隔的 URI 前缀列表，定义了可以使用身份验证信息的所有位置。如果未指定此关键字，则可以在 web 根目录的任意位置使用身份验证信息。
nonce=“<string>”
一串由服务器生成随机字符串，用于加密用户账户与密码，nonce 值对客户端是不透明的。
opaque =“<string>”
一串由服务器生成随机字符串。它的作用是在客户端发送下一次请求时，服务器可以验证客户端的身份。opaque 的值会在服务器收到客户端发送的认证信息后，随后的响应中被包含，客户端需要将这个值在后续的请求中原封不动地发送回服务器。这样做的目的是为了防止重放攻击（replay attack）。攻击者可能会尝试重复发送之前捕获到的认证信息，以此来冒充合法用户。通过在每次响应中更新 opaque 的值，服务器可以确保每个认证信息只能用于一次，从而增加了安全性。
stale=“<bool>” 可选
指示客户端之前的请求因 nonce 太旧了（过期）而被拒绝。如果为 true，则可以使用新的 nonce 加密相同用户名/密码重试请求。如果它是任意其他的值，那么用户名/密码无效，并且必须向用户重新请求。
algorithm=<algorithm> 可选
指定加密算法。有效值是：“MD5”（如果未指定，则是默认）、“SHA-256”、“SHA-512”、“MD5-sess”、“SHA-256-sess”、“SHA-512-sess”。
qop=“<string>”
带引号的字符串，表示服务器支持的保护程度，取值如下：“auth”（身份验证）、“auth-int”（有完整保护的身份验证）。
charset=“UTF-8” 可选
当提交用户名和密码时，告诉客户端服务器的首选编码方案，仅允许值“UTF-8”。
userhash=<bool> 可选
服务器可能指定为 “true”，以指示它支持用户名哈希（默认是 “false”）。

WWW-Authenticate: Basic realm="Access to the staging site", charset="UTF-8"
WWW-Authenticate: Digest
     realm="[email protected]",
     qop="auth, auth-int",
     algorithm=SHA-256,
     nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
     opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
WWW-Authenticate: Digest
     realm="[email protected]",
     qop="auth, auth-int",
     algorithm=MD5,
     nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
     opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"

Authorization请求标头

请求标头Authorization 携带经过正确处理的服务器所需要的用户凭证。客户端在接收 WWW-Authenticate 标头之后，用户代理应该从WWW-Authenticate提供的身份验证方案中选择它支持的最安全的身份验证方案，并提示用户提供凭据，然后重新请求资源，这个新的请求会使用 Authorization 请求标头携带经过相应处理的用户提供的凭证。

参数

用于指定访问该资源需要进行的身份验证方案。一些更常见的身份验证方案是（不区分大小写）：Basic、Digest、Negotiate 和 AWS4-HMAC-SHA256。

除了上述的参数外，该标头对于不同的身份验证方案也有一些不同的参数：

Basic认证

<credentials>
用户提供的凭证，例如账户密码等，并根据指定的方案编码。

Digest认证

response=“<string>”
一串字符串，也被称为响应值，通过将用户名、密码、realm、qop、nc 等值进行结合然后使用nonce加密后的值
username=“<string>”
一串字符串，指定用户名，可以是纯文本，也可以是十六进制表示的哈希编码。
username*=“<string>”
与username相同，如果用户名包含字段中不允许的字符（RFC5987 中定义的扩展符号格式化的用户名）或userhash 设置为 “false” 时，则不可使用username，而是使用username*
uri=“<string>”
一串字符串，指定有效的请求 URI
realm=“<string>”
请求的用户名/密码的 realm（同样，应该与所请求资源中对应的 WWW-Authenticate响应中的值一致）。
opaque=“<string>”
一串由服务器生成随机字符串，为防止重放攻击（同样，应该与所请求资源中对应的 WWW-Authenticate响应中的值一样）。
nonce=“<string>”
一串由服务器生成随机字符串，用于加密用户账户与密码（同样，应该与所请求资源中对应的 WWW-Authenticate响应中的值一样）。
algorithm=<algorithm>
指定加密算法，必须是所请求资源的 WWW-Authenticate响应中支持的算法。
qop=<string>
表示服务器支持的保护程度。必须与在 WWW-Authenticate响应中，为被请求的资源指定的集合中的一个值匹配。
cnonce=“<string>” 可选
客户端生成的随机字符串，这样可以防止攻击者通过简单地重放先前的认证信息来欺骗服务器，并且对特定 nonce 的已知明文攻击，通过在每次认证中使用不同的 cnonce，可以增加攻击者破解认证信息的难度。
nc=<number> 可选
一个数字，它是客户端发送的一个计数器，用于防止重放攻击。每当客户端发送一个新的请求时，它会增加这个计数器的值。服务器会检查这个计数器的值，以确保它是递增的，这样可以防止攻击者重复使用相同的认证信息。
userhash=<bool> 可选
服务器可能指定为 “true”，以指示它支持用户名哈希（默认是 “false”）。

    Authorization: Digest username="Mufasa",
        realm="[email protected]",
        uri="/dir/index.html",
        algorithm=MD5,
        nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
        nc=00000001,
        cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ",
        qop=auth,
        response="8ca523f5e9506fed4657c9700eebdbec",
        opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
        
    Authorization: Digest username="Mufasa",
        realm="[email protected]",
        uri="/dir/index.html",
        algorithm=SHA-256,
        nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
        nc=00000001,
        cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ",
        qop=auth,
        response="753927fa0e85d155564e2e272a28d1802ca10daf449
            6794697cf8db5856cb6c1",
        opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"

有问题，可私信一起讨论学习！