18

What is the difference between using a JSON Web Token (JWT) and simply having an AES key and sending and receiving encrypted JSON from the client?

For example, this could be sent to the client:

AES256.encrypt(JSON.stringify({id: 5552, admin: true}), key)
  • Where comes this AES256.encrypt function? I did a quick look in some libraries none of those uses key as the second argument. Anyway, depending on the library and how you uses it it can be exploited (just an example). – Gustavo Rodrigues Feb 21 '18 at 20:53
  • 1
    @GustavoRodrigues I'm guessing it is meant more to serve as a rephrasing of the idea in pseudo-code (because some people understand that more than a natural language explanation), than to be a specific example. (As in, it may well be intended as a specific example, but even if it was or was an erroneous example, it would still have that explanatory-of-intent value.) – mtraceur Feb 22 '18 at 19:55
33

JSON Web Tokens (= JWTs) are based on the RFC 7519 and all differences will be extensively described there. If you take a look at this, you will see, that they are much more than what you seem to have in mind.
Among other things, these tokens:

  • are used to assert claims (for instance "logged in as admin")
  • are signed with a message authentication code (e.g. HMAC-SHA256) (the algorithm is specified in the header of the JWT)
  • have a payload that contains the claim(s) (equipped with a timestamp)

The signature is base64url encoded. This is described in section 3.1 and Appendix A.1 of the RFC.


You could do all this with an elaborate homegrown implementation of sharing claims, but why would you?
There are standards, norms and RFCs for a reason. They have been tested by experts, they are trusted and people use them for a reason. It's a good thing that (nearly) everybody weighs their fruit in kilos and travels their distance in kilometres. Standardized systems make it easier to share information and are easily usable for a lot of people.

The conclusion to your point behind this: Do not build overly complicated solutions for problems that have tested and trusted solutions.

Also: take a look at this for another "What's the difference..?" question: What's the difference between SHA and AES encryption?

  • 2
    I weigh fruit in pounds (ounces if small) and measure distance in miles. What's my point? I don't have one. – Conor Mancone Feb 22 '18 at 16:06
  • In the case of JWT, the property of being a standard is not proof of quality. Following the standard to the letter is a weakness, specifically the bit about the (attacker-supplied) algorithm in the header needing to be respected in all cases. But more importantly, standards don't prevent people from misusing JWT for purposes it isn't meant to serve. For example, JWT is inappropriate for replacing normal session storage identifiers (not single-use, long-lived, etc.), which seems to be the use case of the OP. None of this is an argument for home-rolling, but does suggest choosing another tech. – Seth Battin Feb 22 '18 at 16:34
  • 2
    @ConorMancone Isn't every single interaction between someone still using the imperic system vs metric/SI a good demonstration of the problems caused by the lack of a single standard being used by everyone? (That said, I think I understand and relate to your underlying sentiment: when someone says "it's a good thing that (almost) everyone does x", and you comfortably go your entire life mostly without every using x, there is a certain desire to point this out.) – mtraceur Feb 22 '18 at 19:58
  • 1
    @mtraceur lol! You clearly understand me – Conor Mancone Feb 22 '18 at 20:17
11

From my other sec.SE answer:

JWT are self sufficient tokens which are used to share authentication information between different systems. They solve the problem of relying on third parties for validating an authentication token as all the information required to validate the JWT is contained within the token itself. This simplifies the process of on-boarding in a single sign-on system as there is minimal integration required. JWT are also HTTP friendly as they are just BASE-64 strings.

You have not provided sufficient information about your application architecture. In your particular case it would be difficult for any other third party or a trusted resource server to validate the AES token issued by you. The only way to do this would be to share your AES encryption key with everyone who wishes to verify the authentication token issued by you. This would be a bad design decision that can have severe confidentiality and integrity issues.

Additionally, tokens need to support important security features like timestamps which allow a resource to prevent token replay attacks. Your design does not support this.

AES256.encrypt(JSON.stringify({id: 5552, admin: true}), key)

Your security token for the admin user with a unique id 5552 is always going to be the same value. In short you should not try to reinvent the wheel and rely on existing methods and frameworks for authentication. JWTs have had their share of security issues in the past. read more .

3

Differences:

  • JWT sends the plaintext and the hmac of it, but you are instead sending the encrypted message
  • JWTs are a standard and have libraries in multiple languages

The problem with your system is that the client cannot read the content of the token (for example which user is the owner).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.