Best HTTP Authorization header type for JWT

Question

I'm wondering what is the best appropriate Authorization HTTP header type for JWT tokens.

One of the probably most popular type is Basic. For instance:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

It handle two parameters such as a login and a password. So it is not relevant for JWT tokens.

Also, I heard about Bearer type, for instance:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

However, I don't know its meaning. Is it related to bears?

Is there a particular way to use JWT tokens in the HTTP Authorization header? Should we use Bearer, or should we simplify and just use:

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Thanks.

Edit:

Or maybe, just a JWT HTTP header:

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Task

Answer 1

The best HTTP header for your client to send an access token (JWT or any other token) is the Authorization header with the Bearer authentication scheme.

This scheme is described by the RFC6750.

Example:

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

If you need stronger security protection, you may also consider the following IETF draft: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-architecture. This draft seems to be a good alternative to the (abandoned?) https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-http-mac.

Note that even if this RFC and the above specifications are related to the OAuth2 Framework protocol, they can be used in any other contexts that require a token exchange between a client and a server.

Unlike the custom JWT scheme you mention in your question, the Bearer one is registered at the IANA.

Concerning the Basic and Digest authentication schemes, they are dedicated to authentication using a username and a secret (see RFC7616 and RFC7617) so not applicable in that context.

Hedge

Thank you! Good to see the origin of this Bearer keyword. But it comes from OAuth. However JWT can be used without OAuth. It's totally independent with OAuth specs. – Task

Yes it comes from the OAuth2 framework protocole, but can be used in any other context. Your server is free to accept JWT using other headers or ways (e.g. in the body request or in the query string), but the Authenticate header more appropriate and is compliant with the RFC7235 which describes an authentication framework in a HTTP 1.1 context – Hedge

I agree with Zag zag, a custom scheme like "JWT" seems way more appropriate than coercing the OAuth2 Bearer scheme into this. – Cosgrove

This should be the accepted answer. Quoting jwt.io/introduction: "the user agent should send the JWT, typically in the Authorization header using the Bearer schema. The content of the header should look like the following: Authorization: Bearer <token>" – Overbearing

If it helps somebody - I came here looking for this example: - curl request using Bearer scheme: curl -H "Authorization: Bearer <TOKEN>" <the rest of your curl cmd> – Gehman

This is the correct answer and should be marked as so, the one marked as the accepted answer was obviously marked as it quickly solved the OP's problem, however in terms of JWT it's very, very bad advice, this answer however is the correct advice. – Noel

One doubt tho, should the token be encoded in base64? – Conah

All tokens shall be url safe encoded. If it is at JWS/JWE, it already uses safe encoding by design (base64url-safe), but if you use another token type, you have to make sure it is suitable for us in the header parameter (e.g. hex is ok but a binary string is not). See rfc-editor.org/rfc/rfc7230#section-3.2 – Hedge

Answer 2

Short answer

The Bearer authentication scheme is what you are looking for.

Long answer

Is it related to bears?

Errr... No :)

According to the Oxford Dictionaries, here's the definition of bearer:

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

1. A person or thing that carries or holds something.

2. A person who presents a cheque or other order to pay money.

The first definition includes the following synonyms: messenger, agent, conveyor, emissary, carrier, provider.

And here's the definition of bearer token according to the RFC 6750:

1.2. Terminology

Bearer Token

A security token with the property that any party in possession of the token (a "bearer") can use the token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove possession of cryptographic key material (proof-of-possession).

The Bearer authentication scheme is registered in IANA and originally defined in the RFC 6750 for the OAuth 2.0 authorization framework, but nothing stops you from using the Bearer scheme for access tokens in applications that don't use OAuth 2.0.

Stick to the standards as much as you can and don't create your own authentication schemes.

---

An access token must be sent in the Authorization request header using the Bearer authentication scheme:

2.1. Authorization Request Header Field

When sending the access token in the Authorization request header field defined by HTTP/1.1, the client uses the Bearer authentication scheme to transmit the access token.

For example:

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

[...]

Clients SHOULD make authenticated requests with a bearer token using the Authorization request header field with the Bearer HTTP authorization scheme. [...]

In case of invalid or missing token, the Bearer scheme should be included in the WWW-Authenticate response header:

3. The WWW-Authenticate Response Header Field

If the protected resource request does not include authentication credentials or does not contain an access token that enables access to the protected resource, the resource server MUST include the HTTP WWW-Authenticate response header field [...].

All challenges defined by this specification MUST use the auth-scheme value Bearer. This scheme MUST be followed by one or more auth-param values. [...].

For example, in response to a protected resource request without authentication:

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

And in response to a protected resource request with an authentication attempt using an expired access token:

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

Holm

Yes. It is related to bears. In the same way that python is related to snakes. Duh. – Titration

Bears.. That does it. Thank you for making my day. – Masera

Is it a vulnerability if : i give the user the token, but when he wants to send me a request he must send the token back in the request body? I will then get it from there and validate? I dont really have other options, as the way they send the request isnt defined by me, but i would be interested if that is any bad or if theres a solution to make it more secure. – Noway

@DanielJeney did you find an answer – Asexual

Bears. Beets. Battlestar Galactica. – Pesach

@DanielJeney It's generally not advisable to come up with your own, non-standard security scheme, but a HTTPS request body is not less secure than a HTTPS request header, so sending the JWT in the body should be OK. See here security.stackexchange.com/questions/97851/… – Sholapur