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

Question

我目前正在处理一组应用程序，这些应用程序在两个不同但等效的环境中运行（称为ENV1和ENV2）。我一直在使用OAuth 2.0进行授权，当我从OAuth服务请求访问令牌后收到响应时（我是通过Postman发出请求的），我会从ENV1 和 ENV2得到类似以下的响应：

据我所知，我相信这个"token_type": "Bearer"的意思是，当我向我的应用程序发送access_token时，我需要这样做：

通过在头部添加 "Bearer" 前缀的 Authorization 标头发送令牌。这种方法在 ENV1 上可以正常工作，但在 ENV2 上请求失败，除非我只发送令牌而不带有 "Bearer" 前缀。

如果我在Authorization头部中带有“Bearer”前缀发送请求，响应会返回401 Unauthorized错误。这是Postman提供的帮助提示（重点是我的）：

类似于403 Forbidden，但特别用于身份验证可能已失败或尚未提供的情况。响应必须包含一个WWW-Authenticate头字段，其中包含适用于所请求资源的挑战。

问题在于这里确实存在一个WWW-Authenticate头字段，并且它包含“Bearer”，我认为这是“适用于所请求资源的挑战”，因为令牌响应包含"token_type": "Bearer"：

---

问题：

• 为什么在不同的环境下会有差异？
• 这怎么可能？我找到的OAuth 2.0文档显示，像我正在尝试进行的请求需要使用“Bearer”前缀。（例如，在文档的第2.1节此处中）

- Flats

---

可能你正在将错误的 token 传递给 env2，或者这两个环境并不完全相同。如果你可以控制环境的话，应该通过记录日志的方式检查服务器端，并查明为何该 token 被拒绝了。 - Juraj Martinka

可能是一个环境问题，但值得注意的是，据我所知，我认为这个"token_type": "Bearer"意味着当我将access_token发送到我的应用程序时，我需要像这样做，这是一个不正确的假设。令牌端点的响应并不自动意味着无论调用任何端点的下一步操作是否接受此令牌作为承载工具。 - identigral

Answer 1

根据您的描述，环境似乎并不完全相同。例如，可能ENV2在网关后面，该网关会向标头添加“Bearer”前缀。或者ENV2上的API（或网关）被配置为读取没有前缀的标头。当OAuth服务器返回访问令牌时，它会给出类型——一个“bearer”令牌。这种类型意味着，该令牌只是一个承载令牌，而不是所有权证明令牌。当您向API发送承载令牌时，无需提供任何其他信息来证明您是令牌的所有者。（您可以将bearer与DPoP标准进行比较）Bearer Token Usage标准确实要求您在授权标头中使用前缀“Bearer”（如您所指出的），但这并不意味着所有API和网关都正确实现了该标准，或者他们根本不使用该标准。总之：

• 网关/API决定授权头部使用何种格式，这与令牌类型（承载令牌）无关。如果他们使用标准是很好的，但并非必须。
• 在您的设置中，如果相同请求在不同环境中得到不同处理，则必须存在某种环境差异。如果您拥有这些环境，应该调查配置方面的差异。如果您不拥有它们，则应联系所有者支持以解决问题。

- Michal Trojanowski

---

可能 ENV1 是 Apache，而 ENV2 是 Nginx，反之亦然，或者其中一个使用代理。 - netizen