How does JWT secure it's values?

Question

I understand JWT is secured. But just wanted to know some concepts which I couldn't understand.

Assume authentication server "A" sends the signed token to application server. If I am not wrong The signing is done by Private key on Server "A". Now the App server can decrypt the token and validate information using Public key. I also read JWT is self contained, it holds both data and signature.

Some of the examples I seen doesn't use any secured key while validating. If I am not wrong RS256 doesn't require any specific keys, I assume it will use public certificates to decrypt.

The query I have is, If JWT is self contained, why cant the data changed in between.

For example assume server "A" sends following information

header.user1email.signature

If The hacker replaces data to

header.user2email.signature

using his own private key, how come that could be a valid data? How can be sure that it has come from server "A"?

I understand am missing some basics here, please help?

Hi @CreativeManix - Did my answers solve your question? If so, would you care to close this question off? — Juxhin, May 05 '17 at 13:06

score 2 · Accepted Answer · edited May 23 '17 at 12:34

2

JWT tokens are constructed by three objects and passed through a SHA256 Hash-based message authentication code (A.K.A HMACSHA256) the following way:

HEADER - Contains the algorithm and type of token (normally JWT)

{
    "alg": "HS256",
    "typ": "JWT" 
}

PAYLOAD - The actual data passed, the is the stateless/self-containing portion

{
  "name": "John Doe"
}

And lastly, your SECRET into something like this (pulled from jwt.io)

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJuYW1lIjoiSm9obiBEb2UifQ.
xuEv8qrfXu424LZk8bVgr9MQJUIrp1rHcPyZw_KSsds

The cool thing is that now, your application doesn't need to interact with its backend database everytime it requires information—instead it can pull it out of the JWT token. As soon as the secret or payload is tampered with in anyway, the signature is invalidated.

This is because the token is normally is signed and encrypted in such a way that requires you to have the private key (SECRET) in order to actually decode it.

EDIT: After scouting through SO, I came across a lovely example provided by Misch. I encourage you to read it!

edited May 23 '17 at 12:34

Community

1
1

answered Feb 02 '16 at 13:24

Juxhin

5,068
8
29
55

I understand it cant be tampered, but that could be replaced with new data including the hash computed for new data right (using hackers own private key)? My doubt is how do we confident that it has come from location what we expecting without a secret key in our end? – CreativeManix Feb 02 '16 at 13:39
@CreativeManix - The example I linked in the answer explains your question - http://stackoverflow.com/questions/27301557/if-you-can-decode-jwt-how-are-they-secure The JWT can only be exchanged successfully between two entities (willingly). A third entity trying to tamper with or change the key in any way would not be able to. This also creates another issue. Since this is stateless, how does the user change payload values (e.g. his profile name)? How do you log a user out if it's truly stateless? – Juxhin Feb 02 '16 at 13:47
Thanks, Yes I did see the SO link provided before asking this question, however still I am not clear. In the example "...They both know some shared secret...". I am clear when secret key is shared between sender and receiver. Because JWT is self-contained I saw some examples without sharing key the data is sent. example: Azure b2c. In those cases how it will be validated? – CreativeManix Feb 02 '16 at 14:32
The example from Misch mentions HS256 (shared secret), azure B2C uses RS256 (RSA public/private key). Azure B2C has a separate URL where you can download the public keys to check the JWT – Erik Oppedijk Feb 06 '16 at 11:31
JWT is not supposed to be used to send encrypted data, but to ensure identity of the sender. – Zelphir Kaltstahl Oct 04 '17 at 11:27
I am sorry to say, but your answer is incorrect. You are talking about HS256 instead of RS256. – GuyT Sep 14 '18 at 11:56
@GuyT -- That's perfectly fine, there is no need to apologise. Could you please edit the answer above, with citations and I will review and accept it if so? Looking back, I agree, HS256 is not the ideal choice due to single key/symmetric encryption. RS256 is the optimal choice due to the use of async public/private keypair. – Juxhin Sep 14 '18 at 12:04

score 0 · Answer 2 · answered Jul 02 '19 at 17:34

In your case, server A signs the message with its own private key, and generating a signature.

Assume server B recieves this entire jwt, it will fetch the public key from server A, and use this public key to check if the message part of this jwt matches with the signature part.

If the message part of the jwt was changed by a hacker, it would not match with the signature. Or even the hacker generated a new signature with his own private key, the public key from A will not verify this message-signature pair.

How does JWT secure it's values?

2 Answers2