JWT的最佳HTTP授权头类型

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

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

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

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

此外，我还听说过持票人类型，例如:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

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

在HTTP Authorization报头中是否有特定的方式使用JWT令牌?我们应该使用Bearer，还是应该简化并只使用:

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

谢谢。

编辑:

或者，可能只是一个JWT HTTP报头:

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
289059 次浏览
小开

客户端发送访问令牌(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方案不同，Bearer是在IANA注册的. c。

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

小开

简短的回答

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

长回答

它和熊有关吗?

哦……没有:)

根据牛津字典，下面是持票人的定义:

持票人 <一口> < em > /ˈbɛːrə/ < / em > < /一口>
名词< / em >

  1. 携带或持有某物的人或物

  2. 付款人:出示支票或其他付款命令的人

第一个定义包括以下同义词:信使， 代理， 输送机， 使者， 航空公司， 提供者。

下面是根据RFC 6750定义的不记名的令牌:

1.2。术语< /强> < / >

不记名的令牌

一种具有财产的安全令牌，任何拥有该令牌的一方(“持有人”)可以以任何其他拥有该令牌的一方可以使用的任何方式使用该令牌。使用不记名令牌并不要求记名者证明拥有加密密钥材料(持有证明)。

Bearer身份验证方案是在IANA注册，最初是在OAuth 2.0授权框架的RFC 6750中定义的，但是没有什么可以阻止你在不使用OAuth 2.0的应用程序中使用Bearer方案作为访问令牌。

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

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

2.1。授权请求报头字段 .

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

例如:

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

[…]

客户端应该使用承载令牌使用Authorization请求报头字段和Bearer HTTP授权方案发出经过身份验证的请求。[…]

在无效或缺少令牌的情况下，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 Unauthorized
WWW-Authenticate: Bearer realm="example",
error="invalid_token",
error_description="The access token expired"

提交答案