What is the difference between JWT and encrypting some json manually with AES?
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?
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 .
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).