JWT的最佳HTTP授权标头类型

Question

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

最受欢迎的类型之一是Basic.例如:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

它处理两个参数,如登录和密码.因此它与JWT令牌无关.

另外,我听说过Bearer类型,例如:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

但是,我不知道它的含义.它与熊有关吗？

是否有一种在HTTP Authorization头中使用JWT令牌的特定方法？我们应该使用Bearer,还是应该简化并使用:

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

谢谢.

编辑:

或者,也许只是一个JWTHTTP标头:

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Answer 1

客户端发送访问令牌(JWT或任何其他令牌)的最佳HTTP标头是Authorization带有Bearer身份验证方案的标头.

该方案由RFC6750描述.

例:

GET /resource HTTP/1.1 Host: server.example.com Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9...TJVA95OrM7E20RMHrHDcEfxjoYZgeFONFh7HgQ

如果您需要更强大的安全保护,您还可以考虑以下IETF草案:https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture.这个草案似乎是(废弃的？)https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac的一个很好的替代方案.

请注意,即使此RFC和上述规范与OAuth2 Framework协议相关,它们也可用于需要在客户端和服务器之间进行令牌交换的任何其他上下文中.

不像定制JWT你在你的问题提方案,将Bearer一个在IANA注册.

关于Basic和Digest身份验证方案,它们专门用于使用用户名和密码进行身份验证(请参阅RFC7616和RFC7617),因此不适用于该上下文.

Answer 2

简短的回答

该Bearer认证方案是你在找什么.

答案很长

它与熊有关吗？

呃...没有:)

根据牛津词典,这里是持票人的定义:

持票人
/bɛːrə/
名词

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

2. 提出支票或其他订单付款的人.

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

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

1.2.术语

持票人令牌

具有属性的安全令牌,即拥有该令牌的任何一方("持票人")可以以任何其他拥有该令牌的方式使用该令牌.使用不记名令牌不需要持票人来证明拥有加密密钥材料(占有证明).

该Bearer认证方案登记在IANA和最初定义的RFC 6750的的OAuth 2.0授权框架,但没有阻止你使用Bearer的访问令牌方案在不使用OAuth 2.0的应用程序.

尽可能坚持标准,不要创建自己的身份验证方案.

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

2.1.授权请求标头字段

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

例如:

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

[...]

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

如果令牌无效或丢失,该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"