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:
Or maybe, just a
JWT HTTP header:
Bearer authentication scheme is what you are looking for.
Is it related to bears?
Errr… No 🙂
According to the Oxford Dictionaries, here’s the definition of bearer:
A person or thing that carries or holds something.
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:
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).
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:
When sending the access token in the
Authorizationrequest header field defined by HTTP/1.1, the client uses the
Bearerauthentication scheme to transmit the access token.
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
Authorizationrequest header field with the
BearerHTTP authorization scheme. […]
In case of invalid or missing token, the
Bearer scheme should be included in the
WWW-Authenticate response header:
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-Authenticateresponse 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"