24

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)
Michael
  • 2,391
  • 2
  • 19
  • 36
FLUSHER
  • 373
  • 1
  • 2
  • 6
  • 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](https://runkit.com/embed/zzwhro2ei8yh) (just an example). – Gustavo Rodrigues Feb 21 '18 at 20:53
  • 2
    @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

4 Answers4

35

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?

Community
  • 1
Tom K.
  • 7,913
  • 3
  • 30
  • 53
  • 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
  • 1
    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
  • 3
    @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
13

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 .

Shurmajee
  • 7,285
  • 5
  • 27
  • 59
4

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).

iovoid
  • 156
  • 3
-1

I think the really only good reason to use them is that browser apps will need a way to authenticate them. That means that if the client code can authenticate them, the code it uses for authenticating them is also going to be visible to any hacker, especially someone who acts a man-in-between, meaning some server on the Internet that is relaying the HTTP requests and responses. So since you are going to expose which encryption algorithm you are using, you might as well use one that is strong, well known and has client libraries that support it. But if your going to rely upon a standard encryption library, you might just as well go all out and use JSON as data format. In the end, you might just as well use JWT as libraries already exist to handle all of this. Personally, I would not include the type of algorithm in the header.

While I cannot say for sure, I highly doubt that any banks use JWT due to their security weakness. So unless you need banking-level encryption and security, JWT is probably good enough for your typical web apps like social networking, YouTube, etc.

AndroidDev
  • 99
  • 1
  • 1
    You contradict yourself a lot in your answer. On one hand you say it's good to use existing libraries to do things for you, then you say you don't want to act according to standard and then do your own thing. And your claim that "no bank uses JWT due to their security weaknesses" is demonstrably false. A number of banks use JWTs, and they do not have any inherent security weaknesses. I would like you to cite some sources on said security weaknesses (inherent to the design of JWT, not some implementation errors). –  Mar 31 '20 at 07:43