JWT的最佳HTTP授权标头类型

Question

我想知道JWT令牌最合适的AuthorizationHTTP头类型是什么。

最流行的类型之一可能是Basic。例如：

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

它处理两个参数，例如登录名和密码。因此，它与JWT令牌无关。

此外，我听说过不记名类型，例如：

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

然而，我不知道它的意思。它和熊有关吗？

在HTTPAuthorization头中是否有使用JWT令牌的特殊方法？我们应该使用承载，还是应该简化并仅使用：

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

谢谢

编辑：

或者，可能只是一个JWTHTTP头：

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Answer 1

Bearer身份验证方案就是您要寻找的。

和熊有关吗？

呃。。。否：）

根据牛津词典，持有者的定义如下：

持票人

>

出示支票或其他付款单的人。

第一个定义包括以下同义词：信使、代理人、传送者、使者、承运人、提供者。

以下是根据RFC 6750对承载令牌的定义：

1.2.名词术语

承载令牌

一种安全令牌，其属性是拥有该令牌的任何一方（“持票人”）可以以任何其他拥有该令牌的一方可以使用的任何方式使用该令牌。使用不记名令牌不要求不记名证明拥有加密密钥材料（拥有证明）。

承载身份验证方案在IANA中注册，最初在用于OAuth 2.0授权框架的RFC 6750中定义，但是没有任何东西阻止您在不使用OAuth 2.0的应用html" target="_blank">程序中使用承载方案来访问令牌。

尽可能地遵守标准，不要创建自己的身份验证方案。

必须使用承载身份验证方案在授权请求标头中发送访问令牌：

2.1. 授权请求标头字段

在HTTP/1.1定义的授权请求头字段中发送访问令牌时，客户端使用承载身份验证方案来传输访问令牌。

例如：

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

[...]

客户端应该使用带有HTTP授权方案的授权请求头字段，使用承载令牌进行身份验证请求。[...]

在令牌无效或丢失的情况下，承载方案应包含在WWW-身份验证响应头中：

3.WWW认证响应头字段

如果受保护资源请求不包括身份验证凭据或不包含允许访问受保护资源的访问令牌，则资源服务器必须包括HTTPWWW-Authenticateresponse-header字段[…]。

本规范定义的所有挑战都必须使用授权方案值承载。这个方案后面必须有一个或多个真参数值。[...]。

例如，响应未经身份验证的受保护资源请求：

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

并且响应于使用过期访问令牌进行身份验证尝试的受保护资源请求：

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
                         error="invalid_token",
                         error_description="The access token expired"

Answer 2

客户端发送访问令牌（JWT或任何其他令牌）的最佳HTTP头是带有承载身份验证方案的授权头。

RFC6750描述了该方案。

示例：

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9TJV...r7E20RMHrHDcEfxjoYZgeFONFh7HgQ

如果您需要更强的安全保护，您也可以考虑以下IETF草案：https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-architecture.该草案似乎是（废弃的？）https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-http-mac.

请注意，即使此RFC和上述规范与OAuth2框架协议相关，它们也可以用于需要客户端和服务器之间令牌交换的任何其他上下文。

与您在问题中提到的自定义JWT方案不同，承载方案是在IANA注册的。

关于基本和摘要身份验证方案，它们专用于使用用户名和密码进行身份验证（请参见RFC7616和RFC7617），因此不适用于该上下文。