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
We can send this token to other endpoints. This can be done easily. We have to add an authorization header in our request and this will be a Bearer TOKEN. To avoid any manual copy-pasting of JWT token, we can use variables to add a script in the Tests tab of API request which is generating token.
A JSON Web Token (JWT, pronounced "jot") is a compact and url-safe way of passing a JSON message between two parties. It's a standard, defined in RFC 7519. The token is a long string, divided into different parts separated with dots, and each part is base64 encoded.
The jwt specification recommends (but does not require) sending the access tokens in an authorization header of type Bearer.
Header. The header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA. For example: { "alg": "HS256", "typ": "JWT" } Then, this JSON is Base64Url encoded to form the first part of the JWT.
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.
The 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:
bearer /ˈbɛːrə/
noun
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:
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 theBearer
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 theBearer
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"
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With