http - 为什么我的授权 header 不需要 "Bearer"？

Question

我目前正在处理一组在两个独立但等效的环境(称为 ENV1 和 ENV2)上运行的应用程序。我一直在使用 OAuth 2.0 进行授权，当我从 OAuth 服务请求访问 token 后收到响应时(我通过 Postman 发出请求)我从 ENV1 < em>和 ENV2:

据我所知，我相信这个 "token_type": "Bearer" 意味着当我将 access_token 发送到我的应用程序时，我需要做像这样:

通过 Authorization header 发送 token ，前缀为“Bearer”。这种方法在 ENV1 上运行良好，但在 ENV2 上请求失败除非我单独发送没有“承载”前缀:

如果我发送带有“Bearer”前缀的 Authorization header ，我会得到一个 401 Unauthorized 错误作为响应。这是Postman提供的帮助提示(重点是我的):

Similar to 403 Forbidden, but specifically for use when authentication is possible but has failed or not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource.

这里的问题是 IS 有一个 WWW-Authenticate header 字段，它包含“Bearer”，我认为是一个“适用于所请求资源的挑战”，因为 token 响应包含 "token_type": "Bearer":

---

问题:

• 为什么环境之间会有所不同？
• 这怎么可能？ 我在 OAuth 2.0 上找到的文档显示，像我尝试发出的请求一样，需要“Bearer”前缀。 (例如，在文档 here 的第 2.1 节中)

Answer 1

从您的描述来看，环境似乎并不完全相同。例如。也许 ENV2 在网关后面，该网关将 Bearer 前缀添加到 header 。或者 ENV2(或网关)上的 API 配置为读取没有前缀的 header 。

当 OAuth 服务器返回访问 token 时，它会为您提供类型 - bearer token 。该类型意味着， token 就是这个 - 不记名 token - 而不是所有权证明 token 。当您向 API 发送不记名 token 时，您无需提供任何额外信息来证明您是 token 的所有者。 (你可以将 bearer 与 DPoP 标准进行比较)

Bearer Token Usage 标准确实要求您在授权 header 中使用前缀 Bearer(正如您所指出的)，但这并不意味着所有 API 和网关都正确地实现了该标准，或者他们根本不使用该标准。

总结:

• 由网关/API 决定他们想要授权 header 的格式，这与 token (不记名 token )的类型无关。他们使用标准很好，但他们不必这样做。
• 在您的设置中，如果相同的请求在环境之间的处理方式不同，则环境之间肯定存在某种差异。如果您拥有这些环境，您应该调查不同配置的内容。如果您不拥有它们，您应该联系所有者的支持来解决问题。