JWT 的最佳 HTTP 授权标头类型
我想知道最适合 JWT tokens 的 Authorization HTTP 标头类型是什么。
可能最受欢迎的类型之一是 Basic。例如：
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
它处理两个参数，例如登录名和密码。所以它与 JWT 令牌无关。
另外，我听说过 Bearer 类型，例如：
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
但是，我不知道它的含义。跟熊有关系吗？
是否有在 HTTP Authorization 标头中使用 JWT 令牌的特殊方法？我们应该使用 Bearer，还是应该简化并只使用：
Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
谢谢。
编辑：
或者，也许只是一个 JWT HTTP 标头：
JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
客户端发送访问令牌（JWT 或任何其他令牌）的最佳 HTTP 标头是具有 Bearer 身份验证方案的 Authorization 标头。
此方案由 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 方案不同，the Bearer one is registered at the IANA。
关于 Basic 和 Digest 身份验证方案，它们专用于使用用户名和密码进行身份验证（请参阅 RFC7616 和 RFC7617），因此不适用于该上下文。
简短的回答
Bearer 身份验证方案正是您要寻找的。
长答案
跟熊有关系吗？
错误...没有:)
根据 Oxford Dictionaries，bearer 的定义如下：
bearer /ˈbɛːrə/ 名词 携带或持有某物的人或物。出示支票或其他命令付款的人。
第一个定义包括以下同义词：使者、代理人、传送者、使者、承运人、提供者。
以下是根据 RFC 6750 对 bearer token 的定义：
1.2.术语 持有者令牌 一种安全令牌，具有任何拥有令牌的一方（“持有者”）可以以任何其他拥有它的一方可以使用的任何方式使用令牌的属性。使用不记名令牌不需要不记名证明拥有加密密钥材料（所有权证明）。
Bearer 身份验证方案是 registered in IANA，最初在 RFC 6750 中为 OAuth 2.0 授权框架定义，但没有什么能阻止您在不使用 OAuth 2.0 的应用程序中使用 Bearer 方案访问令牌。
尽可能坚持标准，不要创建自己的身份验证方案。
必须使用 Bearer 身份验证方案在 Authorization 请求标头中发送访问令牌：
2.1。 Authorization Request Header Field 当在 HTTP/1.1 定义的 Authorization 请求头域中发送 access token 时，客户端使用 Bearer 认证方案来传输 access token。例如：GET /resource HTTP/1.1 主机：server.example.com 授权：Bearer mF_9.B5f-4.1JqM [...] 客户端应该使用带有承载 HTTP 授权的 Authorization 请求标头字段使用承载令牌发出经过身份验证的请求方案。 [...]
如果令牌无效或丢失，Bearer 方案应包含在 WWW-Authenticate 响应标头中：
3. WWW-Authenticate 响应头域 如果受保护的资源请求不包含认证凭证或不包含允许访问受保护资源的访问令牌，则资源服务器必须包含 HTTP WWW-Authenticate 响应头域 [.. .]。本规范定义的所有挑战必须使用 auth-scheme 值 Bearer。该方案必须后跟一个或多个 auth-param 值。 [...]。例如，响应未经身份验证的受保护资源请求：HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm="example" 并且响应使用过期访问令牌进行身份验证尝试的受保护资源请求：HTTP/1.1 401未经授权的 WWW-Authenticate: Bearer realm="example", error="invalid_token", error_description="访问令牌已过期"
关注公众号
不定期副业成功案例分享
Bearer关键字的来源。但它来自 OAuth。但是 JWT 可以在没有 OAuth 的情况下使用。它完全独立于 OAuth 规范。Authenticate标头更合适，并且符合描述 HTTP 1.1 中的身份验证框架的 RFC7235语境curl -H "Authorization: Bearer <TOKEN>" <the rest of your curl cmd>