最适合JWT的HTTP授权头类型

Question

我想知道使用哪种HTTP头部Authorization最适合JWT令牌。

其中可能最流行的类型之一是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

- Zag zag..

Answer 1

客户端发送访问令牌（JWT或其他令牌）最好使用带有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。这个草案似乎是(abandoned?) https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-http-mac的一个很好的替代品。

请注意，即使这个RFC和上述规范与OAuth2框架协议有关，它们也可以在需要客户端和服务器之间进行令牌交换的任何其他情况下使用。

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

关于 Basic 和 Digest 认证方案，它们专门用于使用用户名和密码进行身份验证（请参见 RFC7616 和 RFC7617），因此在该上下文中不适用。

- Spomky-Labs

---

谢谢！很高兴看到Bearer这个关键字的起源。但它来自OAuth。然而，JWT可以在不使用OAuth的情况下使用。它完全独立于OAuth规范。 - Zag zag..

是的，它来自OAuth2框架协议，但可以在任何其他上下文中使用。您的服务器可以自由地接受使用其他标头或方式（例如，在请求正文或查询字符串中）的JWT，但“Authenticate”标头更为适当，符合RFC7235的规定，在HTTP 1.1上下文中描述了一个身份验证框架。 - Spomky-Labs

这应该是被接受的答案。引用 https://jwt.io/introduction/ 的内容："用户代理应该发送JWT，通常在Authorization头部使用Bearer架构。头部的内容应该如下所示：Authorization: Bearer <token>"。 - wrschneider

如果有帮助的话 - 我来这里是为了寻找这个示例：- 使用Bearer方案的curl请求：curl -H "Authorization: Bearer <TOKEN>" <其余的curl命令> - Kevin Friedheim

这是正确的答案，应该标记为正确答案。被标记为被接受的答案显然是因为它快速解决了OP的问题，但就JWT而言，这是非常糟糕的建议。相比之下，这个答案才是正确的建议。 - shawty

Answer 2

简短回答

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

详细解答

这和熊有关系吗？

嗯...不，没有 :)

根据牛津词典的定义，这是bearer的定义：

bearer _{^/ˈbɛːrə/}
noun

1. 承载或持有某物的人或事物。

2. 向银行呈现支票或其他支付命令的人。

第一个定义包括以下同义词：messenger, agent, conveyor, emissary, carrier, provider。

以下是RFC 6750中对bearer token的定义：

1.2. 术语

Bearer Token

具有以下属性的安全令牌：持有该令牌（“bearer”）的任何一方都可以像其他持有者一样使用该令牌。使用承载令牌不需要承载人证明对加密密钥材料的持有（POPs）。

Bearer身份验证方案在IANA注册，最初是在OAuth 2.0授权框架的RFC 6750中定义的，但是您可以在不使用OAuth 2.0的应用程序中使用Bearer方案来访问令牌。

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

---

访问令牌必须使用Bearer身份验证方案在Authorization请求头中发送：

2.1. Authorization Request Header Field

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

例如：

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

[...]

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

如果令牌无效或缺失，则应在WWW-Authenticate响应头中包括Bearer方案：

3. WWW-Authenticate响应头字段

如果受保护的资源请求未包含身份验证凭据或未包含允许访问受保护资源的访问令牌，则资源服务器必须在HTTP WWW-Authenticate响应头字段中包含以下内容[...]。

此规范定义的所有挑战必须使用Bearer认证方案值。此方案必须后跟一个或多个auth-param值。[...]

例如，对于没有身份验证的受保护资源请求的响应：

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"

- cassiomolin

---

是的，它与熊有关。就像Python与蛇有关一样。显而易见。 - Nicholas Hamilton

熊...太棒了。谢谢你让我过了一个愉快的一天。 - user2501323

如果我将令牌提供给用户，但当他想要向我发送请求时，他必须在请求正文中发送令牌，这是否会存在漏洞？然后我会从那里获取并验证它。我实际上没有其他选择，因为他们发送请求的方式不是由我定义的，但我很感兴趣是否存在任何问题或是否有解决方案可以使其更安全。 - Daniel Jeney

@DanielJeney 你有找到答案吗？ - vikrant

熊。甜菜。《星际迷航：卡拉狄加》。 - Vitor Braga

@DanielJeney 通常不建议自己设计非标准的安全方案，但是使用 HTTPS 请求体并不比使用 HTTPS 请求头不安全，因此在请求体中发送 JWT 应该是可以的。请参见此处 https://security.stackexchange.com/questions/97851/https-post-request-header-versus-request-body - Dario Seidl