I'm testing an application that sends JWT token in the request body (in JSON) instead of the header. Is it less secure than sending JWT token in the request header (like Authorization header), which is more popular?
4
-
Probably duplicate of security.stackexchange.com/q/130548/3034– Ben VoigtCommented Sep 14, 2022 at 15:13
-
@BenVoigt apparently none of the answers there address the issue here imho– Sir MuffingtonCommented Sep 14, 2022 at 15:37
-
In JWT the main deal is that only you have the private key, which partly addresses the issue here but does not answer the question fully imho– Sir MuffingtonCommented Sep 14, 2022 at 15:41
-
sending in the header (or cookie) is more popular as it's usually sent/read in a more global fashion, where data "models" are usually different for different requests/responses. (you'd need to add this field to all of those frontend/backend models if sent via JSON request body) Adding the JWT as a custom header also helps ensure that the requests cannot be sent as simple requests, so will go through pre-flight checks if cross-origin. (helps prevent CSRF attacks)– browsermatorCommented Feb 8 at 20:18
Add a comment
|
1 Answer
The security of JWT is not related to the transmission method, but to the algorithm which creates the JWT.
A JWT token is meant to be public, so be it in a header or as POST data, it really doesn't matter, as the purpose of the token is not to be hidden. That's why it's important not to expose the private key, as only with the valid private key you can generate a valid Signature which will be verified by the server.
Remember that the most common case is that the server generates a new token, provides it to the client, and then the client uses it. If the client-to-server transmission is intercepted and the content of the payload changed, it won't matter because once the server verifies the token, it will deemed it invalid because the Signature will not be expected, as the attacker doesn't have access to the Secret.
For this reason, it's important to verify the token on the server. I have analyzed services which didn't do that, resulting in the compromise of the system. An example, a user could fetch all the private information of other users because the server didn't validate the token, so just crafting a payload with a different user ID was enough to retrieves their content.
-
1I think I'd use another word than "public"; JWTs are absolutely not meant to be public in the same sense as e.g. public keys (anybody can see them, share them, use them for their intended purpose). It's meant to be visible to the client and the verifying party, which might be the client, a back-end server for the client app, the minting server, or a third-party server. I'm also not sure what you mean by "hidden"; neither (custom) headers nor body are any more or less visible to either client or server. Commented Sep 15, 2022 at 7:34
-
"JWTs are absolutely not meant to be public": Well it depends, on the JWT. JWT used a bearer (access) tokens are not meant to be public. JWTs with proof-of-possession could be public (but they could contain PII so it's usually not a great idea). Other kind of JWTs may be public.– ysdxCommented Jun 6 at 15:04