1
votes

JWT is meant to allow the exchange of a token that is tamper-proof when a client needs to communicate with the backend. It also serves to avoid making calls to the backend datastore by caching session data in the token.

But I could just as easily encrypt the session data using standard encryption algorithms and sent it back to the client and the client just returns it on each call.

So what have I really gained by using JWT? If anything, putting the type of algorithm in the JWT seems to be a security flaw as it tells a hacker what kind of encryption was used, thus reducing the types of algorithms needed to decrypt the token. By just encoding my session data in some proprietary format (not necessarily JSON) and using even a custom encryption algorithm, wouldn't this be a better solution than using JWT? Or would I be missing out on something by not using JWT?

1
The benefits of standardized and, more importantly, thoroughly reviewed and tested software seems self-evident to me, especially in cryptography. If it doesn't to you I'm not sure what kind of answer you expect. Knowledge of the used cryptographic primitives doesn't compromise security. Your "custom encryption algorithm" (and its implementation) has a near-zero chance of being secure. - Peter
Actually being a standard doesn't make something viable when it comes to security. I highly doubt that any banks use JWT in their apps. Disclosing your encryption algorithm to hackers is bad no matter how well you can justify using standards. Financial institutions are very unlikely to do that. - Johann

1 Answers

1
votes

First of all:

Disclosing your encryption algorithm to hackers is bad

No, it is not. You should never try to enhance security by using non-standard algorithms. This is "security by obscurity". As kerckhoffs principle states, the security of a algorithm should only be based on the secrecy of the key, not the algorithm.

Concerning the actual question: You should use JWT (or any other standardised method) over just encrypting session data (which is basically just building your own token mechanism), because it supports way more functionality out of the box. You will probably need way less time using jwt than implementing and testing your own solution.

Also there are probably many security relevant aspects (e.g. token replay attacks, etc.) that you might not be aware of. Therefore it is pretty difficult to implement such a system which is secure in any currently known way. It is always better to use tested and trusted solutions as long as they provide the features you need.

More information: https://security.stackexchange.com/questions/180208/what-is-the-difference-between-jwt-and-encrypting-some-json-manually-with-aes