授权请求（Authorization）

API 使用授权来确保客户端请求安全地访问数据。这可能涉及对请求的发送者进行身份验证，并确认他们有权访问或操作相关数据。如果你正在构建 API，则可以从多种身份验证模型中进行选择。如果你要集成第三方 API，所需的授权将由 API 提供商指定。

你可以将身份验证详细信息与你在 Postman 中发送的任何请求一起传递。授权数据可以包含在 header、正文中，或作为请求的参数。如果你在“授权”选项卡中输入你的身份验证详细信息，Postman 将自动为你选择的身份验证类型填充请求的相关部分。你可以使用变量和集合来更安全有效地定义授权细节，使你能够在多个地方重复使用相同的信息。

在 Postman 中打开请求后，使用“授权”选项卡选择身份验证类型，然后完成所选类型的相关详细信息。正确的数据值将由服务器端的 API 确定。如果你使用的是第三方 API，请参阅提供商的文档以了解任何所需的身份验证详细信息。

某些公共 API 可以使用更简单的 API 身份验证。有关详细信息，请参阅 公共 API 的身份验证 。

你可以将这些身份验证类型与 Newman 和监视器以及 Postman 一起使用。

当你从“类型”下拉列表中选择一种类型时，Postman 将指示你的详细信息将包含在请求的哪些部分中，例如 header、正文、URL 或查询参数。当你选择或输入它们时，Postman 会将你的身份验证详细信息添加到请求的相关部分，因此你可以在运行请求之前预览数据的发送方式。

你的授权数据将出现在请求的相关部分，例如标题选项卡中。要显示自动添加的标题，请选择hidden。

将鼠标悬停在标题上以获取有关添加位置的信息。要更改授权 header，请返回授权选项卡并更新你的配置。

你不能直接在“header”选项卡中覆盖由你的**授权选择添加的 header。如果你需要与 Postman 自动生成的不同的身份验证 header，请更改 Authorization**中的设置，或删除你的身份验证设置并手动添加 header。

你的请求授权可以使用环境、集合和全局 变量 。Postman 不保存 header 数据或查询参数，以避免暴露 API 密钥等敏感数据。

发送后，你可以在 Postman 控制台中检查整个请求的原始转储，包括身份验证数据。

公共 API 的身份验证

越来越多的公共 API 通过 Postman 提供更简单的身份验证，包括 Stripe、Open AI、Notion 和 Spotify。当你向受支持的 API 创建请求时，Postman 将自动识别 API 是否需要身份验证，并为你提供设置新授权的选项。

选择设置新授权以了解发出请求所需的身份验证凭据以及在哪里可以找到它们。对于支持 OAuth 2.0 的 API，可以选择Authorize完成授权。对于需要令牌或 API 密钥等凭据的 API，你可以将它们直接粘贴到你的请求中。

如果你是 API 发布者，则可以 加入候补名单 ，以便为你的公共 API 向 Postman 社区提供更轻松的身份验证。为此，请打开 Postman 并选择右上角的团队，然后**选择团队设置 > 设置 API 授权。或者，从 Postman header 中选择API Network ，然后选择**Public API Network > Set up API authorization。

继承授权

如果你将请求分组到 集合 和文件夹中，则可以指定要在整个组中重复使用的身份验证详细信息。

默认情况下，集合或文件夹内的请求将从父级继承身份验证，这意味着它们将使用你在文件夹或集合级别指定的相同身份验证。要为单个请求更改此设置，请在请求授权选项卡中进行不同的选择。

授权类型

从授权选项卡上的**类型**下拉列表中选择一种类型。你可以为请求、集合或文件夹选择授权类型。

无授权

除非你指定身份验证类型，否则 Postman 不会随请求发送授权详细信息。如果你的请求不需要授权，请从授权选项卡类型下拉列表中选择**无授权**。

API 密钥

使用 API 密钥身份验证，你可以在请求 header 或查询参数中向 API 发送键值对。在请求授权选项卡中，从类型列表中选择API 密钥。输入你的键名和值，然后从“添加到”下拉列表中选择“header”或“查询参数”。你可以将你的值存储在变量中以获得额外的安全性。

Postman 会将相关信息附加到你的请求Headers或 URL 查询字符串中。

不记名令牌

不记名令牌使请求能够使用访问密钥进行身份验证，例如 JSON Web 令牌 (JWT)。令牌是一个文本字符串，包含在请求 header 中。在请求授权选项卡中，从类型下拉列表中选择Bearer Token。在令牌字段中，输入你的 API 密钥值。为了增加安全性，将其存储在一个变量中并按名称引用该变量。

Postman 会将令牌值Bearer以要求的格式附加到请求授权 header 的文本中，如下所示：

如果需要自定义前缀，请使用密钥为Authorization 的 API 密钥 。

JWT 承载

Postman 还支持生成 JWT 承载令牌来授权请求。你可以在编辑器中输入负载，然后生成 JWT 令牌并将其添加到请求中。在请求授权选项卡中，从类型下拉列表中选择JWT Bearer。

• 将 JWT 令牌添加到- 选择请求 header或查询参数以指定将 JWT 令牌添加到你的请求的方式。

• 算法- 选择用于 JWT 令牌的算法。支持的算法包括：

  • HS - 带 SHA 的 HMAC
  • RS - 带 SHA 的 RSA (RSASSA-PKCS1-v1_5)
  • ES - 带 SHA 的 ECDSA
  • PS - 带 SHA 的 RSA (RSASSA-PSS)

• 秘密- 与 HMAC-SHA 算法一起使用的秘密。

• 秘密 Base64 编码- 如果秘密以 base-64 格式编码。

• 私钥- 用于为 RS、ES 和 PS 算法签署令牌的私钥。选择选择文件以上传 PKCS #8 格式的私钥。

• 负载- 以 JSON 格式输入 JWT 令牌的负载数据。

在高级配置部分，你还可以配置以下项目。如果你不配置它们，它们会自动生成。

• header 前缀- 在 header 开头使用的可选前缀。此 header 前缀是请求的一部分，而不是 JWT 的一部分。
• header- 你还希望在 JWT 令牌中发送的任何自定义 header。与所选算法相关的 header 会自动添加。

基本授权

基本身份验证涉及在你的请求中发送经过验证的用户名和密码。在请求授权选项卡中，从类型下拉列表中选择基本身份验证。

在用户名和密码字段中输入你的 API 用户名和密码。为了额外的安全性，将它们存储在变量中。

在请求header中，授权 header 向 API 传递一个 Base64 编码的字符串，表示你的用户名和密码值，附加到文本中，Basic如下所示：

Basic <Base64 encoded username and password>

摘要认证

使用 Digest auth，客户端向 API 发送第一个请求，服务器以一些详细信息作为响应，包括只能使用一次的数字（随机数）、领域值和401未经授权的响应。然后，你发送回一个加密的数据数组，其中包括用户名和密码，以及在第一个请求中从服务器接收到的数据。服务器使用传递的数据生成加密字符串并将其与你发送的内容进行比较以验证你的请求。

在请求的Authorization选项卡中，从Type 下拉列表中选择**Digest Auth。Postman 将为身份验证请求的两个阶段提供字段。它将使用第一个请求从服务器返回的数据自动完成高级部分中第二个请求的字段。要使 Postman 能够自动执行流程，请输入用户名和密码**值（或变量），这些值将与第二个请求一起发送。

如果你不希望 Postman 自动提取数据，请在左侧栏中选择是，禁用重试请求。如果这样做，你将需要完成高级字段并手动运行每个请求。

在高级部分中设置字段是可选的。当你的第一个请求运行时，Postman 会自动填充它们。

• Realm - 服务器在WWW-Authenticate响应 header 中指定的字符串。
• Nonce - 服务器在WWW-Authenticate响应 header 中指定的唯一字符串。
• 算法- 一个字符串，指示用于生成摘要和校验和的一对算法。Postman supportMD5和SHA算法。
• qop - 应用于消息的保护质量。该值必须是服务器在WWW-Authenticate响应 header 中指定的选项之一。
• Nonce Count - 客户端使用此请求中的 nonce 值发送的请求数（包括当前请求）的十六进制计数。
• Client Nonce - 客户端提供的不透明引用字符串值，客户端和服务器都使用它来避免选择的明文攻击，提供相互身份验证，并提供一些消息完整性保护。
• 不透明- 由服务器在响应 header 中指定的一串数据WWW-Authenticate，将与同一保护空间中的 URI 一起使用。

OAuth 1.0

OAuth 1.0 使客户端应用程序能够访问第三方 API 提供的数据。例如，作为服务的用户，你可以授予另一个应用程序访问你使用该服务的数据的权限，而无需暴露你的用户名和密码等详细信息。使用 OAuth 1.0 访问用户数据涉及客户端应用程序、用户和服务提供商之间的一些来回请求。

OAuth 1.0 有时被称为“两条腿”（仅在客户端和服务器之间进行身份验证）或“三条腿”（客户端为第三方服务的用户请求数据）。示例 OAuth 1.0 流程可以按如下方式运行：

• 要使用第三方服务请求用户数据，消费者（客户端应用程序）使用密钥和秘密等凭据请求访问令牌。
• 服务提供者发出初始令牌（不提供对用户数据的访问），消费者请求用户授权。
• 当用户授予身份验证时，消费者发出请求以将临时令牌交换为访问令牌，从而通过用户身份验证的验证。
• 服务提供者返回访问令牌，然后消费者可以向服务提供者请求访问用户的数据。

Postman support OAuth Core 1.0 Revision A 。

要使用 OAuth 1.0，请执行以下操作：

1. 在请求的授权选项卡中，从类型下拉列表中选择OAuth 1.0 。

2. 从下拉列表中选择签名方法。这将决定哪些参数包含在你的请求中。Postman supportHMAC-SHA1, HMAC-SHA256, HMAC-SHA512, RSA-SHA1, RSA-SHA256,RSA-SHA512和PLAINTEXT。

   • 如果你的服务器需要HMACorPLAINTEXT签名，Postman 将提供Consumer Key、Consumer Secret、Access Token和Token Secret字段。
   • 如果你使用RSA签名，Postman 将提供Consumer Key、Access Token和Private Key输入。

3. 你可以选择设置高级详细信息——否则 Postman 将尝试自动完成这些。

4. 你可以在请求 header 或正文/URL 中包含身份验证详细信息。从“将授权添加到”下拉列表中选择一项。如果你想检查详细信息将如何包含在请求中，请打开“标题”或“正文”选项卡。

如果你在 header 中发送 OAuth 1.0 数据，发送你的密钥和秘密值的授权 header 将附加到字符串以及OAuth其他以逗号分隔的必需详细信息。

当你完成授权设置中的所有必填字段后，Postman 会将 OAuth 1.0 信息附加到请求header。

如果你在正文和 URL 中发送 OAuth 1.0 数据，则数据将添加到请求正文或参数中，具体取决于请求方法。

如果请求方法是POST或PUT，并且请求正文类型是x-www-form-urlencoded，Postman 将在请求正文中添加授权参数。否则，例如在GET请求中，你的密钥和机密数据将在 URL 查询参数中传递。

OAuth 1.0 auth 参数值如下：

• 签名方法- 你的 API 用于验证请求的方法。
• Consumer Key - 用于向服务提供商标识消费者的值。
• 消费者秘密- 消费者用来建立密钥所有权的值。（对于HMAC和PLAINTEXT签名方法。）
• 访问令牌- 代表消费者访问用户数据的权限的值。
• Token Secret - 消费者用来建立给定令牌所有权的值。（对于HMAC和PLAINTEXT签名方法。）
• 私钥- 用于生成身份验证签名的私钥。（对于RSA签名方法。）
• 高级参数：
  • 回调 URL - URL 服务提供商将重定向到以下用户授权。（如果你的服务器使用 OAuth 1.0 修订版 A，则为必需。）
  • Verifier - 用户授权后来自服务提供商的验证码。
  • 时间戳- 服务器用来防止时间窗口外的重播攻击的时间戳。
  • Nonce - 客户端生成的随机字符串。
  • 版本- OAuth 身份验证协议的版本 (1.0)。
  • Realm - 服务器在WWW-Authenticate响应 header 中指定的字符串。
  • 包括主体散列-用于与 . 以外的 请求主体进行完整性检查的散列application/x-www-form-urlencoded。（当你使用回调 URL / 验证器时停用。）

如果你的 OAuth 1.0 服务器实现需要它，请选择Add empty parameters to signature。

你还可以选中复选框以对请求的授权 header 中的参数进行编码。

OAuth 2.0

使用 OAuth 2.0，你首先检索 API 的访问令牌，然后使用该令牌对未来的请求进行身份验证。访问令牌通常是短期的，但授权服务器也可以提供长期的刷新令牌。客户端应用程序可以使用刷新令牌自动 刷新访问令牌 。

使用 OAuth 2.0 访问数据在 API 服务提供商之间差异很大，但通常涉及客户端应用程序、用户和 API 之间的一些来回请求。示例 OAuth 2.0 流程可以按如下方式运行：

• 客户端应用程序请求用户授权访问他们的数据。
• 如果用户授予访问权限，则应用程序会向服务提供商请求访问令牌，传递来自用户的访问权限和身份验证详细信息以识别客户端。
• 服务提供商验证这些详细信息并返回一个短期访问令牌和一个长期刷新令牌。
• 客户端使用访问令牌向服务提供商请求用户数据。
• 当访问令牌过期时，客户端可以使用刷新令牌自动请求新的访问令牌。

要使用 OAuth 2.0，请执行以下操作：

1. 在集合或请求的授权选项卡中，从类型下拉列表中选择OAuth 2.0 。指定是否要在请求 URL 或 header 中传递身份验证详细信息。

   默认情况下，Postman 会将访问令牌附加到Bearer你请求的授权 header 中，但如果你的服务器实现需要不同的前缀，你可以在header 前缀字段中指定它。

2. 要请求访问令牌，请填写 Configure New Token部分中的字段，然后选择Get New Access Token。要将令牌用于你的请求或集合，请选择继续，然后选择使用令牌。你用于生成令牌的详细信息与你的请求或集合一起保存。你还可以 共享令牌 ，以便其他有权访问该集合的人可以使用该令牌。

   生成并添加令牌值后，它将出现在请求header中。

3. 输入你的客户端应用程序的详细信息，以及来自服务提供商的任何身份验证详细信息。这允许你在 Postman 中复制你的应用程序身份验证流程以测试经过身份验证的请求。

   你可以与你的团队共享令牌凭据。打开Share token开关，然后选择Sync Token。默认情况下，Postman 不会同步你的令牌，以防你不想共享它。

4. Postman 将根据 OAuth 2.0 授权类型提示你提供特定详细信息，授权类型可以是 授权代码 、 隐式 、 密码凭据 或 客户端凭据 。

授权码

授权代码授予类型要求用户向提供者进行身份验证——然后将授权代码发送回客户端应用程序，提取并与提供者交换访问令牌以验证以后的请求。

要使用授权代码授予类型，请输入客户端应用程序的回调 URL（需要向 API 提供商注册），以及 API 服务提供的各种详细信息，包括Auth URL、Access Token URL、Client ID和Client Secret .

如果你使用的是 Postman 桌面应用程序，则可以通过选择 Authorize using browser在 Web 浏览器而不是 Postman 中输入你的身份验证详细信息。

授权码（带 PKCE）

你可以将 PKCE（用于代码交换的证明密钥）与 OAuth 2.0 一起使用。当你选择Authorization Code (With PKCE)时，另外两个字段将可用于Code Challenge Method和Code Verifier。你可以选择使用SHA-256或Plain算法来生成代码挑战。验证器是一个可选的 43-128 字符的字符串，用于将授权请求连接到令牌请求。

建议使用授权码（使用 PKCE）授权类型与使用浏览器进行授权相结合，以防止授权码拦截攻击。

隐含的

隐式授权类型向客户端返回一个访问令牌，而不需要额外的授权代码步骤（因此安全性较低）。

要在 Postman 中对你的请求使用隐式授权类型，请输入你已向 API 提供商注册的回调 URL 、提供商**Auth URL以及你已注册的应用程序的客户端 ID 。**

如果你使用的是 Postman 桌面应用程序，则可以通过选择 Authorize using browser在 Web 浏览器而不是 Postman 中输入你的身份验证详细信息。

密码凭据

OAuth 2.0 密码授予类型涉及直接从客户端发送用户名和密码，因此如果你正在处理第三方数据，则不推荐使用。

要使用密码授予类型，请输入你的 API 提供商的访问令牌 URL以及用户名和密码。在某些情况下，你还需要提供客户端 ID 和密码。

客户端凭据

客户端凭据授权类型通常不用于访问用户数据，而是用于与客户端应用程序关联的数据。

输入提供商的Access Token URL，以及你注册的应用程序的Client ID和Client Secret。

请求 OAuth 2.0 令牌

请求新访问令牌的完整参数列表如下，具体取决于你的授权类型。

在Configure New Token下，输入有关令牌的详细信息：

• 令牌名称- 你要用于令牌的名称。
• 授权类型- 选项的下拉列表。这将取决于 API 服务提供商的要求。
• 回调 URL - 验证后重定向到的客户端应用程序回调 URL。这必须向 API 提供商注册。如果未提供，Postman 将使用默认的空 URL 并尝试从中提取代码或访问令牌。如果这对你的 API 不起作用，你可以使用以下 URL：https://oauth.pstmn.io/v1/browser-callback
  • Authorize using browser -> 如果你使用的是 Postman 桌面应用程序，则可以通过选择**Authorize using browser在 Web 浏览器而不是 Postman 中输入你的身份验证详细信息。使用授权代码或隐式授权类型时，选中此复选框以设置回调 URL**以返回到 Postman。如果你选择使用浏览器进行授权，请确保回调 URL 的弹出窗口已停用，否则将无法使用。
• Auth URL - API 提供者授权服务器的端点，用于检索授权代码。
• 访问令牌 URL - 提供商的身份验证服务器，用于交换访问令牌的授权代码。
• 客户端 ID - 在 API 提供商处注册的客户端应用程序的 ID。
• 客户端密码- API 提供者提供给你的客户端密码。
• 范围- 你请求的访问范围，可能包括多个以空格分隔的值。
• State - 防止跨站点请求伪造的不透明值。
• 客户端身份验证- 在 header 中发送基本身份验证请求，或在请求正文中发送客户端凭据。升级到新版本后，更改此处的值以避免客户端身份验证出现问题。

选择高级选项以自定义令牌：

• 刷新令牌 URL - 刷新服务器的端点，用于将刷新令牌交换为访问令牌。如果为空，刷新令牌 URL 将与访问令牌 URL 相同。
• Auth Request、Token Request和Refresh Request - 定义要与 auth 请求、token 请求或刷新请求一起发送的任何自定义参数。对于你定义的每个键值对，选择一个选项以在请求正文、请求 URL 或请求 header 中发送参数。
  • 如果你添加多个具有相同键名的键，它们将作为数组与请求一起发送。
  • 如果你在以前版本的 Postman 中添加了资源或受众 URI，则可以将它们作为自定义参数导入。选择受众和资源选项卡以查看资源和受众，然后选择移动受众和资源。对于除隐式之外的所有授权类型，参数都添加到令牌请求中。对于隐式授权类型，参数被添加到授权请求中。

配置完成后，选择Get New Access Token。配置信息与访问令牌一起保存，每次刷新令牌时都会使用。

当你使用授权代码或隐式授权类型时，系统将提示你提供凭据以检索访问令牌以在以后的请求中使用。默认情况下，当你选择 Request Token时，Postman 将显示一个弹出窗口。如果你使用的是 Postman 桌面应用程序，则可以改为选择使用系统的默认 Web 浏览器进行身份验证。选择Authorize using browser设置在浏览器完成认证后回调 URL 返回给 Postman，这样你的请求就可以使用认证成功返回的 token。

来自 API 的令牌包括其详细信息、到期时间和可选的刷新令牌，你可以在当前令牌到期时使用它来检索新的访问令牌。选择继续，然后选择使用令牌以使用返回的令牌。

任何成功检索到的令牌都将列在请求可用令牌下拉列表中。选择一个与你的请求一起发送。在下拉列表中选择管理令牌以查看更多详细信息或删除你的令牌。

如果身份验证失败或超时，Postman 将显示一条错误消息。你可以在控制台中检查错误详细信息，重试以再次尝试身份验证，或者在继续之前编辑你的身份验证详细信息。

在 Postman 中删除令牌不会撤销访问权限。只有颁发令牌的服务器才能撤销它。

刷新 OAuth 2.0 令牌

在 Postman 中生成的 OAuth 2.0 令牌过期之前，Postman 会在你发送使用它的请求之前自动在后台刷新它。刷新的访问令牌会在使用它的任何请求中更新。如果你在 生成令牌 时添加了任何自定义参数，这些参数也将用于刷新的令牌。

自���刷新是默认行为。要关闭或打开此功能，请选择自动刷新访问令牌。要手动刷新令牌，请选择Refresh。如果令牌在第二天到期，则会显示令牌的到期时间。

存在刷新令牌时可以使用自动刷新。如果不存在刷新令牌，则自动刷新访问令牌切换和手动刷新选项不可用。要检查是否存在刷新令牌，请在令牌下拉列表中选择**管理令牌**。如果不存在刷新令牌，请检查授权服务。没有刷新令牌，Postman 无法刷新访问令牌。

你可以在手动发送请求时使用自动刷新。自动刷新不用于同一集合的计划运行或监视器。

共享 OAuth 2.0 访问令牌

要使其他 Postman 用户能够查看和使用 OAuth 2.0 访问令牌，请选择共享访问令牌。

要撤销其他用户对同步令牌的访问权限，请执行以下操作：

1. 关闭共享访问令牌。
2. 选择删除同步令牌。

在你撤销访问权限后，有权访问该请求的其他用户将无法查看或使用该令牌。

更改 OAuth 2.0 令牌类型

Postman support 使用访问令牌或 ID 令牌进行 OAuth 2.0 授权。访问令牌使 OAuth 客户端能够调用 API。ID令牌包含有关经过身份验证的用户的信息。OAuth 客户端可以使用此信息来定制他们的体验。

如果存在 ID 令牌，你可以在使用令牌类型下拉列表中选择令牌类型（访问令牌或ID 令牌）。如果不存在 ID 令牌，则此下拉列表不可用。要检查 ID 令牌是否存在，请在令牌下拉列表中选择**管理令牌**。

霍克认证

Hawk 身份验证使你能够使用部分加密验证来授权请求。

要使用 Hawk 身份验证，请执行以下操作：

1. 在请求的授权选项卡中，从类型下拉列表中选择**Hawk 身份验证**。
2. 在 Hawk Auth ID、Hawk Auth Key和Algorithm字段中输入你的详细信息。你可以选择设置高级详细信息，但 Postman 会在必要时尝试为它们生成值。

当你的请求的 Authorization选项卡中的所需详细信息完成后，Postman 会将它们添加到 Headers中。

Hawk 认证参数如下：

• Hawk Auth ID - 你的 API 身份验证 ID 值。
• Hawk Auth Key - 你的 API 身份验证密钥值。
• 算法- 用于创建消息验证代码 (MAC) 的哈希算法。
• 高级参数：
  • 用户- 用户名。
  • Nonce - 客户端生成的随机字符串。
  • ext - 与请求一起发送的任何特定于应用程序的信息。
  • app - 凭据和应用程序之间的绑定，以防止攻击者使用颁发给其他人的凭据。
  • dlg - 凭据颁发给的应用程序的 ID。
  • 时间戳- 服务器用来防止时间窗口外的重放攻击的时间戳。

AWS 签名

AWS 是 Amazon Web Services 请求的授权工作流程。AWS 使用基于键控 HMAC（哈希消息身份验证代码）的自定义 HTTP 方案进行身份验证。

官方 AWS 签名文档提供了更多详细信息：

• 签署和验证 REST 请求
• 使用 Postman 调用 API

要使用 AWS 签名，请执行以下操作：

1. 在请求的授权选项卡中，从类型下拉列表中选择AWS 签名。

2. 使用 Add authorization data to下拉列表，选择请求 header 或 URL，选择 Postman 将附加你的 AWS 身份验证详细信息的位置。

   • 如果你选择Request Headers ，Postman 将在**Headers**选项卡中添加Authorization和X-Amz-前缀字段。
   • 如果你选择Request URL ，Postman 将在**Params**中添加 auth 详细信息，并以 keys 为前缀X-Amz-。

3. 直接在字段中输入你的访问密钥和秘密值。为了额外的安全性，你可以为这些值使用 秘密变量 。

4. 你可以选择设置高级字段，但 Postman 会在必要时自动生成这些字段。

AWS 签名参数如下：

• AWS 区域- 接收请求的区域（默认为us-east-1）。
• 服务名称- 接收请求的服务。
• 会话令牌- 仅在使用临时安全凭证时需要。

NTLM 身份验证

Windows 质询/响应 (NTLM) 是 Windows 操作系统和独立系统的授权流程。

要使用 NTLM 身份验证，请执行以下操作：

1. 在请求的授权选项卡中，从类型下拉列表中选择NTLM 身份验证。
2. 输入用于 NTLM 访问的用户名和密码（使用变量以避免直接输入值）。你可以选择指定高级参数，但 Postman 会在必要时尝试自动完成这些参数。默认情况下，你的请求将在提取第一次收到的数据后运行第二次。你可以通过选中复选框来关闭此行为。

NTLM auth 的高级参数如下：

• 域- 要进行身份验证的域或主机。
• 工作站- PC 的主机名。

Akamai EdgeGrid

Akamai EdgeGrid 是 Akamai 开发和使用的授权助手。

要使用 Akamai EdgeGrid，请执行以下操作：

1. 在请求的授权选项卡中，从类型下拉列表中选择Akamai EdgeGrid 。
2. 输入你的Access Token、Client Token和Client Secret，使用变量以提高安全性——当你向 Akamai 注册客户端应用程序时，你将收到这些详细信息。

当你的请求的 Authorization选项卡中的所需详细信息完成后，Postman 会将它们添加到 Headers中。

有关获取凭据的信息，请参阅 Akamai 开发人员 - 授权你的客户端 。

同步 cookie

如果你的浏览器中有会话 cookie，你可以使用拦截器将它们同步到 Postman。有关详细信息，请参阅 拦截器扩展 和 Cookie 。

故障排除

如果你在获取请求以进行身份验证并成功运行时遇到问题，请查看 API 请求故障排除 中的提示。如果你仍然有身份验证问题，请查看 Postman 论坛上的 身份验证标签。