为什么我的授权标头不需要“Bearer”？

Question

我目前正在使用一组应用程序，这些应用程序在两个独立但等效的环境中运行（称为

ENV1

和

ENV2

）。我一直在使用 OAuth 2.0 进行授权，当我从 OAuth 服务请求访问令牌后收到响应时（我通过 Postman 发出请求），我得到的响应如下所示：

ENV1

and

ENV2

:

据我所知，我相信这

"token_type": "Bearer"

意味着当我将

access_token

发送到我的申请时，我需要这样做：

通过

Authorization

标头发送令牌，前缀为“Bearer”。这种方法在

ENV1

上工作正常，但在

ENV2

上请求失败除非我单独发送令牌，不带“Bearer”前缀：

如果我发送带有“Bearer”前缀的

Authorization

标头，我会收到

401 Unauthorized

错误作为响应。这是Postman提供的帮助提示（重点是我的）：

与 403 Forbidden 类似，但专门用于可以进行身份验证但失败或尚未提供身份验证的情况。响应

必须包含 WWW-Authenticate 标头字段
，其中包含适用于所请求资源的质询。
这里的问题是，有

IS 一个 WWW-Authenticate 标头字段，并且它包含“Bearer”，我认为这是一个“适用于所请求资源的挑战”，因为令牌响应包含

"token_type": "Bearer"

：

问题：

Answer 1

Bearer

前缀添加到标头的网关后面。或者 ENV2（或网关）上的 API 配置为读取不带前缀的标头。

当 OAuth 服务器返回访问令牌时，它会为您提供类型 -

bearer

令牌。这种类型意味着，令牌就是这样的——不记名令牌——而不是所有权证明令牌。当您将不记名令牌发送到 API 时，您无需提供任何其他信息来证明您是令牌的所有者。（可以将承载与

DPoP

标准进行比较）承载令牌使用标准确实要求您在授权标头中使用前缀

Bearer

（正如您所指出的），但这并不意味着所有 API 和网关都正确实现该标准，或者它们使用该标准完全没有。

总结一下：

由网关/API 决定他们想要什么格式的授权标头，这与令牌（不记名令牌）的类型无关。他们使用标准很好，但他们不必这样做。

在您的设置中，如果相同的请求在环境之间得到不同的处理，那么环境之间一定存在某种差异。如果您拥有这些环境，则应该调查哪些配置不同。如果您不拥有它们，您应该联系所有者的支持来解决问题。