Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why send algorithm in jwt header

Tags:

jwt

jwt-auth

In JWT token we send the algorithm type used for signing the JWT in header which is just base64 encoded. Anyone can know the algorithm easily.eg

{ "alg":"HS256" }

Why do we send it to the client as there is no need for the client to know it. Isn't not sending the algorithm more secure ?

like image 835
megamind11 Avatar asked Jan 03 '20 19:01

megamind11


People also ask

Where in the JWT header will you find information about the type of algorithm used?

JOSE header This header describes what algorithm (signing or encryption) is used to process the data contained in the JWT. The JOSE header typically defines two attributes: alg and typ . typ: the content that is being signed or encrypted (usually 'JWT').

What algorithm you should use in JWT token?

JWTs are most commonly signed using one of two algorithms: HS256 (HMAC using SHA256), and RS256 (RSA using SHA256).

What does the header of JWT contain?

Anatomy of a JWT The header typically consists of two parts: the type of the token, which is JWT, and the algorithm that is used, such as HMAC SHA256 or RSA SHA256. It is Base64Url encoded to form the first part of the JWT. The payload contains the claims.

How do I send JWT tokens in headers?

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.


2 Answers

HS256 is a signature algorithm so the client (as you have described it) can read the contents of the token anyway, without verifying the signature (unless the content is encrypted separately).

It is a good point that if the receiver of the token needs it then there is no good reason to send a copy of it in the token. In fact it was a criticism of JWT that the algorithm is included in the header and this led to various vulnerabilities in libraries implementing the standard, particularly since it includes a none option for the signature algorithm which allowed the sender of a token to bypass verification completely if the receiver only used the information in the JWT header (see this article for more information). This also details another vulnerability due to weakly typed signing keys.

It's now often recommended that the verifier of a token specify what algorithm it expects it to be using (since in many cases this will be known), rather than rely on the information in the JWT header.

So the problem is not so much about exposing information about the algorithm used (the algorithms should be robust enough for it to make no difference), but about receiving invalid algorithm information which can be used to deceived the receiver of the token into believing it is valid when it is actually forged.

like image 57
Shaun the Sheep Avatar answered Oct 07 '22 20:10

Shaun the Sheep


Why do we send it to the client

The obvious, pedantic reason is simply that the standard requires it:

RFC 7515 4.1.1
This Header Parameter MUST be present and MUST be understood and processed by implementations.

While I don't know this for sure as I can't find any IETF meeting notes discussing it, I believe the algorithm is required because of historical precedent. These standards did not just appear over-night, on their own, in the form we know them today. Rather they evolved from the XML dsig technology, where algorithm is specifically sent as part of embedded public keys.

Isn't not sending the algorithm more secure ?

Requiring implementations to change behavior based on client input is questionable. The alg header is client-provided, which means even if it's valid, it can be used to trick the implementation into open failure modes. Two critical vulnerabilities were exploited almost immediately after JWT was standardized, based on allowing the client to direct the server as to the algorithm choice.

Whether this is a design bug or an implementation bug has been debated.

Bottom line, the JOSE family (JWT, JWS, JWE, JWK, and JWA) allows implementors and users to mix and match cryptographic algorithms, which offers a huge array of use-case capability. Unfortunately, it also means users should be extremely picky about their JWT library's handling of client-provided algorithm.

If you're looking into other bearer-token type options, options that don't have this unusual (bizarre?) requirement, check-out:

  • PASETO
  • Macaroons
like image 37
bishop Avatar answered Oct 07 '22 18:10

bishop