If you can decode JWT, how are they secure?

Question

If I get a JWT and I can decode the payload, how is that secure? Couldn't I just grab the token out of the header, decode and change the user information in the payload, and send it back with the same correct encoded secret?

I know they must be secure, but I just would really like to understand the technologies. What am I missing?

Lilliamlillian

md5('original messaged' + secret) != md5('changed message' + secret) thus if someone changes the message you can detect it – Ironclad

true for an ideal case, however, md5 has collisions. @Ironclad – Quartziferous

@YashKumarVerma yes, it's just to demonstrate the gist of it since everyone knows md5. – Ironclad

@Ironclad how do you know the original messaged? – Salvatoresalvay

@Salvatoresalvay it is base64 encoded, NOT encrypted. You can simply decode it with any base64 decoder. – Ironclad

so the client will need to send both the hash and the jwt token? and later on in the server side they will try to hash the jwt token using secret and compare with the hash? – Salvatoresalvay

This can help too https://mcmap.net/q/65582/-jwt-authentication-concept – Downfall

A server should never trust the client to handle and return sensible data. Only hashes that the server can then internally use to retrieve the actual data, most likely from a database. – Millpond

Answer 1

JWTs can be either signed, encrypted or both. If a token is signed, but not encrypted, everyone can read its contents, but when you don't know the private key, you can't change it. Otherwise, the receiver will notice that the signature won't match anymore.

Answer to your comment: I'm not sure if I understand your comment the right way. Just to be sure: do you know and understand digital signatures? I'll just briefly explain one variant (HMAC, which is symmetrical, but there are many others).

Let's assume Alice wants to send a JWT to Bob. They both know some shared secret. Mallory doesn't know that secret, but wants to interfere and change the JWT. To prevent that, Alice calculates Hash(payload + secret) and appends this as signature.

When receiving the message, Bob can also calculate Hash(payload + secret) to check whether the signature matches. If however, Mallory changes something in the content, she isn't able to calculate the matching signature (which would be Hash(newContent + secret)). She doesn't know the secret and has no way of finding it out. This means if she changes something, the signature won't match anymore, and Bob will simply not accept the JWT anymore.

Let's suppose, I send another person the message {"id":1} and sign it with Hash(content + secret). (+ is just concatenation here). I use the SHA256 Hash function, and the signature I get is: 330e7b0775561c6e95797d4dd306a150046e239986f0a1373230fda0235bda8c. Now it's your turn: play the role of Mallory and try to sign the message {"id":2}. You can't because you don't know which secret I used. If I suppose that the recipient knows the secret, he CAN calculate the signature of any message and check if it's correct.

J

So the signature is changed when the payload is changed? I was under the impression the token was in the format [header].[payload].[signature] is the signature calculated by combination of the payload and secret? If that was the case, wouldn't a payload with a different id be the same for that secret? Like if the data was { id:1 } and that is used to calculate the signature part of the token with the secret, wouldn't that mean that { id:2 } would be valid for user 2, and so user 1 could change id to 2 and the token would be the same? – Lilliamlillian

For instance I'm going here and changing the data in the payload and it says signature valid unless i enter invalid characters: jwt.io grab.by/CNGS – Lilliamlillian

Thanks, but it seems like if Mallory changes the hash by changing the id in the payload, Hash(newContent+secret) would be valid. So does this mean I have to send the user with the request to match against the JWT? I am wondering if I can't rely on the payload to tell me who is doing the request. – Lilliamlillian

Oh I understand now. I don't know why I was missing the idea that the secret hash would not be correct when you changed the payload because the secret hash would have to be recalculated. For some reason I was still thinking that it was independent. That last bit really drilled it home for me. Thanks for walking me through it. – Lilliamlillian

I have a related question. What's preventing someone from impersonating Alice with the copied JWT? – Panne

If someone has the JWT they can impersonate Alice. So you need to be careful how you store and send it. You should also set an expiry for it in the payload. That way if someone steals the JWT they have a limited timeframe to use it. Have a look at stormpath.com/blog/… – Rotarian

@Panne I've ran into the issue of users "sharing" tokens. What we did to improve security was to use the user's IP address as part of the decrypting process. Because this happened in the back-end; a user could share a token with another but get denied not knowing why. At the same time we destroyed/invalidated the shared token so both users would have to sign in again and get a new token. Of course, this is not perfect because you could still get away with it if you were connected to the same network. What I'd love to see is a browser enforced session ID passed via the headers. – Dixiedixieland

if someone with copied jwt can impersonate alice, then what is the use of jwt then , is not is better to use a simple encrypted key that is different for every user and generated at the time of signup and saved in database.atleast to save development time. – Fitzsimmons

The assumption made is that secret is not known. Say I know the secret and hash method you are using, then I can pretend to be any user in the system. How do you solve this problem? – Antonomasia

PKI with RSA may be used to make tokens more secure. Thus server will have Public Key of user and user will have Private Key stored in Cryptographic Device like HSM or USB Token or Smart Card, which never comes out of such device and has no chance of compromise. Use RS256 to sign JWT then. – Kassab

In this example, is Mallory able to verify the integrity of the JWT and if so, how can she do it without the secret? – Condiment

@Condiment No, not in this example. Using HMAC (symmatrical cryptography) was only to illustrate the example. If you need a third party to be able to verify the integrity of the JWT, you can use an asymmetrical signing algorithm. – J

I know this is an old question but nobody mentioned it here. Setting the expiry (Geraint Anderson mentioned) for JWT tokens in case they are stolen is usually done by refresh tokens. #27726566 . So basically I steal a token but it is valid only for 5 minutes. Usually the site is responsible for generating a new one in the background so that user doesn't have to relog after it expires – Darn

Answer 2

Let's discuss from the very beginning:

JWT is a very modern, simple and secure approach which extends for Json Web Tokens. Json Web Tokens are a stateless solution for authentication. So there is no need to store any session state on the server, which of course is perfect for restful APIs. Restful APIs should always be stateless, and the most widely used alternative to authentication with JWTs is to just store the user's log-in state on the server using sessions. But then of course does not follow the principle that says that restful APIs should be stateless and that's why solutions like JWT became popular and effective.

So now let's know how authentication actually works with Json Web Tokens. Assuming we already have a registered user in our database. So the user's client starts by making a post request with the username and the password, the application then checks if the user exists and if the password is correct, then the application will generate a unique Json Web Token for only that user.

The token is created using a secret string that is stored on a server. Next, the server then sends that JWT back to the client which will store it either in a cookie or in local storage.

Just like this, the user is authenticated and basically logged into our application without leaving any state on the server.

So the server does in fact not know which user is actually logged in, but of course, the user knows that he's logged in because he has a valid Json Web Token which is a bit like a passport to access protected parts of the application.

So again, just to make sure you got the idea. A user is logged in as soon as he gets back his unique valid Json Web Token which is not saved anywhere on the server. And so this process is therefore completely stateless.

Then, each time a user wants to access a protected route like his user profile data, for example. He sends his Json Web Token along with a request, so it's a bit like showing his passport to get access to that route.

Once the request hits the server, our app will then verify if the Json Web Token is actually valid and if the user is really who he says he is, well then the requested data will be sent to the client and if not, then there will be an error telling the user that he's not allowed to access that resource.

All this communication must happen over https, so secure encrypted Http in order to prevent that anyone can get access to passwords or Json Web Tokens. Only then we have a really secure system.

So a Json Web Token looks like left part of this screenshot which was taken from the JWT debugger at jwt.io. So essentially, it's an encoding string made up of three parts. The header, the payload and the signature Now the header is just some metadata about the token itself and the payload is the data that we can encode into the token, any data really that we want. So the more data we want to encode here the bigger the JWT. Anyway, these two parts are just plain text that will get encoded, but not encrypted.

So anyone will be able to decode them and to read them, we cannot store any sensitive data in here. But that's not a problem at all because in the third part, so in the signature, is where things really get interesting. The signature is created using the header, the payload, and the secret that is saved on the server.

And this whole process is then called signing the Json Web Token. The signing algorithm takes the header, the payload, and the secret to create a unique signature. So only this data plus the secret can create this signature, all right? Then together with the header and the payload, these signature forms the JWT, which then gets sent to the client.

Once the server receives a JWT to grant access to a protected route, it needs to verify it in order to determine if the user really is who he claims to be. In other words, it will verify if no one changed the header and the payload data of the token. So again, this verification step will check if no third party actually altered either the header or the payload of the Json Web Token.

So, how does this verification actually work? Well, it is actually quite straightforward. Once the JWT is received, the verification will take its header and payload, and together with the secret that is still saved on the server, basically create a test signature.

But the original signature that was generated when the JWT was first created is still in the token, right? And that's the key to this verification. Because now all we have to do is to compare the test signature with the original signature. And if the test signature is the same as the original signature, then it means that the payload and the header have not been modified.

Because if they had been modified, then the test signature would have to be different. Therefore in this case where there has been no alteration of the data, we can then authenticate the user. And of course, if the two signatures are actually different, well, then it means that someone tampered with the data. Usually by trying to change the payload. But that third party manipulating the payload does of course not have access to the secret, so they cannot sign the JWT. So the original signature will never correspond to the manipulated data. And therefore, the verification will always fail in this case. And that's the key to making this whole system work. It's the magic that makes JWT so simple, but also extremely powerful.

Tourniquet

hi @Lord, this is awsome! I dont know why it is with so less up votes! – Alumna

hi @ani0904071, In the below link you will find an example with node.js, I hope it will help too. #31310259 – Tourniquet

This answer is great! In very simplified form, if the JWT was "2.5.9" (header=2, payload=5, signature=9) then tampering with it and changing the data to 6 wouldn't work. Let's say the servers secret is multiplying header*payload and subtracting 1. The "test signature" would be 2*6-1=11. But the JWT's signature is 9, so the server knows that something has been tampered with. It's easy once understood, but for some reason many articles leave out the low-level stuff, which makes it seem more magical and complicated than it really is. – Vacuity

Thanks, now I understand it. So simple, yet so hard to grasp. Now it seems trivial. – Braziel

AWESOME EXPLANATION! – Columbarium

@Lord, how is it secure if the hacker doesn't tweak jwt but uses the same jwt instead to make and retrieve some important data? Won't server would believe that it's a genuine request? Or is there something I am missing? – Abstention

@infinite I believe this keywords will help you, JWT , Auth, PrivateRoute, AdminRoute – Tourniquet

@Lord, doesn't seem to be helping much. – Abstention

The problem is not what happens when one modifies the JWT. The problem is what happens when person B can access a JWT of person A (eg they sit next to each other, person A goes to toilet, person B opens dev tools in person A's chrome and copy pastes the JWT from local storage and sends it to his pc), and uses this to issue calls in the API. How is it possible to tell that the request coming from person's B pc (but is actually issued to person A) is invalid? – Lyndy

@ThanasisIoannidis this reminds me of Session Hijacking, but somehow different, since Session Hijacking's primary manner of attack would be sniffing.. Now, for your case, Person B would still be, somehow, 'Hijacking' Person's A JWT Token.. In a sniffing case, this would be resolved by using HTTPS, now, in your case, there's not much we can do. It's an infosec concern to actually educate the employees to not let their PCs unlocked when not at the desk. – Tadzhik

This post makes it clear! Many of the online materials confuse us with shared secret between client and server and client creates jwt with payload, header and private key and server decodes the payload+header but with its public key. Looks like thats not the case and its just server that decodes the JWT and checks if it's same. This makes the design simple as we don't share secret with client. – Fullbodied

Does server keeps the test signature to match the incoming token to server. Or it follow some algo their. – Thoraco

I've been looking for JWT explanation like this for a 2 weeks. Awesome job, @Lord! Thank you! – Lancelancelet

@Lord Really in-depth info, much appreciated but I have one last concern. The JWT secret is stored in our server correct ? if so, can it be leaked ? can i trust .env variables in my server that keeps JWT secret ? – Commutate

@emre-ozgun, yes you can, keep two separate .env files. one for your local development and the other for server build, it is a very common practice. – Tourniquet

This is a good explanation. I understand a lot now. Thanks – Lansquenet

I don't see how JWTs are useful for authentication. They do NOT prove the person holding the JWT is who they say they are. From your answer: "Once the request hits the server, our app will then verify if the Json Web Token is actually valid and if the user is really who he says he is", the JWT doesn't prove the requestor's identity, the JWT just proves what level of access the holder of the JWT has. – Reputed

@Reputed As I understand; the user specifies its identity on the payload so the server can use that specific user's secret to validate it. – Trine

@M.Erkin, yes, but the token can be exfiltrated and used by anyone else within the token's lifetime. The token doesn't prove who I am because I just successfully impersonated you by exfiltrating the token. The "JWT for authentication" is more "JWT is for authentication because you can only get a JWT once you authenticate, so we're hoping you're the real person not someone who stole a JWT". JWT is for authorization via claims, but you can try to use JWT for authentication via the implication that the user has already proven their identity to the AuthenticationService. – Reputed

Answer 3

You can go to jwt.io, paste your token and read the contents. This is jarring for a lot of people initially.

The short answer is that JWT doesn't concern itself with encryption. It cares about validation. That is to say, it can always get the answer for "Have the contents of this token been manipulated"? This means user manipulation of the JWT token is futile because the server will know and disregard the token. The server adds a signature based on the payload when issuing a token to the client. Later on it verifies the payload and matching signature.

The logical question is what is the motivation for not concerning itself with encrypted contents?

1. The simplest reason is because it assumes this is a solved problem for the most part. If dealing with a client like the web browser for example, you can store the JWT tokens in a cookie that is secure (is not transmitted via HTTP, only via HTTPS) and httpOnly (can't be read by Javascript) and talks to the server over an encrypted channel (HTTPS). Once you know you have a secure channel between the server and client you can securely exchange JWT or whatever else you want.

2. This keeps thing simple. A simple implementation makes adoption easier but it also lets each layer do what it does best (let HTTPS handle encryption).

3. JWT isn't meant to store sensitive data. Once the server receives the JWT token and validates it, it is free to lookup the user ID in its own database for additional information for that user (like permissions, postal address, etc). This keeps JWT small in size and avoids inadvertent information leakage because everyone knows not to keep sensitive data in JWT.

It's not too different from how cookies themselves work. Cookies often contain unencrypted payloads. If you are using HTTPS then everything is good. If you aren't then it's advisable to encrypt sensitive cookies themselves. Not doing so will mean that a man-in-the-middle attack is possible--a proxy server or ISP reads the cookies and then replays them later on pretending to be you. For similar reasons, JWT should always be exchanged over a secure layer like HTTPS.

Dunite

Mind it! JWT should always be exchanged over a secure layer like HTTPS – Edessa

But if JWT is only secure over HTTPS, why not just send the payload? POST -> username, password. It is still encrypted right? – Greybeard

@Greybeard for that you should read up on JWT basics but Session Auth like you mention is often all you need. JWT offers some other benefits but makes some tradeoffs webskeleton.com/webdev/2019/10/22/… – Dunite

You just read what is in my mind, In fact, as I am newbie I was surpised that jwt.io can read my payload so what the signature is doing exactelly ? now my biggest question What Happens If Your JWT Is Stolen?!!! – Doorbell

This is the answer I was looking for. Thanks @Dunite – Fronniah

Sensitive information like password, credit card details, etc. MUST not be encoded in JWT – Fronniah

What I've understood is that it is very similar to the old school session_id with some payload where information is passed to the client and afterwards verified on the next requests. It helps the server to become stateless. – Truss

If you can create a JWT that has any payload - what is there from having a nefarious actor just creating a JWT that says "I am username XYZ"? – Courtier

@Courtier The server has to verify the signature of JWTs. Server only grants permission if the JWT was signed using its own private key. In this case, since the server didn't sign them, it wont grant permission. – Apomixis

@Dunite the provided link does not work anymore. – Woodie

Answer 4

The contents in a json web token (JWT) are not inherently secure, but there is a built-in feature for verifying token authenticity. A JWT is three base64 encoded strings separated by periods. The third is the signature. In a public/private key system, the issuer signs the token signature with a private key which can only be verified by its corresponding public key.

It is important to understand the distinction between issuer and verifier. The recipient of the token is responsible for verifying it.

There are two critical steps in using JWT securely in a web application: 1) send them over an encrypted channel, and 2) verify the signature immediately upon receiving it. The asymmetric nature of public key cryptography makes JWT signature verification possible. A public key verifies a JWT was signed by its matching private key. No other combination of keys can do this verification, thus preventing impersonation attempts. Follow these two steps and we can guarantee with mathematical certainty the authenticity of a JWT.

More reading: How does a public key verify a signature?

Lashonlashond

A JWT is not three hashes. The header and payload are not hashes, they are cleartext, encoded with Base64Url encoding, a variant of base64 encoding. The signature is a hash, and maybe hashed with the private key of a public/private pair or it may simply be hashed with a secret, typically known only to the server, but required by anyone who wants to confirm that the JWT is valid. If a recipient of a JWT lacks the secret, it will be impossible for them to verify the JWT. – Excess

Answer 5

I would explain this with an example.

Say I borrowed $10 from you, then I gave you an IOU with my signature on it. I will pay you back whenever you or someone else bring this IOU back to me, I will check the signature to make sure that is mine.

I can't make sure you don't show the content of this IOU to anyone or even give it to a third person, all I care is that this IOU is signed by me, when someone shows this IOU to me and ask me to pay it.

The way how JWT works is quite the same, the server can only make sure that the token received was issued by itself.

You need other measures to make it secure, like encryption in transfer with HTTPS, making sure that the local storage storing the token is secured, setting up origins.

Kelci

Perfect analogy! – Carnassial

> encryption in transfer with HTTPS, making sure that the local storage storing the token is secured, setting up origins < Please explain in more detail how to do it? – Hallie

Answer 6

It is important to note that JWT are used for authorization and not authentication. So a JWT will be created for you only after you have been authenticated by the server by may be specifying the credentials. Once JWT has been created for all future interactions with server JWT can be used. So JWT tells that server that this user has been authenticated, let him access the particular resource if he has the role.
Information in the payload of the JWT is visible to everyone. There can be a "Man in the Middle" attack and the contents of the JWT can be changed. So we should not pass any sensitive information like passwords in the payload. We can encrypt the payload data if we want to make it more secure. If Payload is tampered with server will recognize it.
So suppose a user has been authenticated and provided with a JWT. Generated JWT has a claim specifying role of Admin. Also the Signature is generated with

This JWT is now tampered with and suppose the role is changed to Super Admin
Then when the server receives this token it will again generate the signature using the secret key(which only the server has) and the payload. It will not match the signature in the JWT. So the server will know that the JWT has been tampered with.

Reposted from my Blog Post - JWT Structure and Security

Lowering

+1 for emphasizing that JWTs are NOT for authn, but for authz. I don't know why so many sites and people say they are for authn. JWTs do NOT prove the identity of the requestor at ALL. I guess everyone is trying to make the inference that a requestor would only have a JWT AFTER they've authenticated to your service, but that isn't necessarily true. – Reputed

Just curious.. @Reputed Why do you think JWT not considered as authentication token? It has the payload where the user-info is present. The header, payload and secret key are used to “validate" the original signature (which was initially generated by the authentication server) which means if any change in payload then user is said to be not original user and hence not authentic. Isn't it simplifies the authn process i.e. with token we can authenticate the user for every request without going to authentication server again and then allow the access to resource based on user role. – Replication

cloud.google.com/api-gateway/docs/authenticating-users-jwt explains other way to what this answer explains. – Replication

Answer 7

Only JWT's privateKey, which is on your server will decrypt the encrypted JWT. Those who know the privateKey will be able to decrypt the encrypted JWT.

Hide the privateKey in a secure location in your server and never tell anyone the privateKey.

Grandiloquence

JWTs are not always encrypted. They can be signed, encrypted, signed then encrypted, or encrypted then signed. – Yaakov

Answer 8

I am not a cryptography specialist and hence (I hope) my answer can help somebody who is neither.

There are two possible ways of using cryptography in programming:

1. Signing / verifying
2. Encryption / decryption

We use Signing when we want to ensure that data comes from a trusted source. We use Encryption when we want to protect the data.

Signing / verifying uses asymmetrical algorithms i.e. we sign with one key (private) and the data receiver uses the other (public) key to verify.

A symmetric algorithm uses the same key to encrypt and decrypt data.

The encryption can be done using both symmetric and asymmetric algorithms. relatively simple article on subject

The above is common knowledge below is my opinion.

When JWT is used for simple client-to-server identification there is no need for signing or asymmetric encryption. JWT can be encrypted with AES which is fast and supersecure. If the server can decrypt it, it means the server is the one who encrypted it.

Summary: non-encrypted JWT is not secure. Symmetric encryption can be used instead of signing in case no third party is involved.

Hexamerous

Answer 9

	Paswords	JsonWebtoken
Validity	Until password is changed or a changed is enforced eg. after 90 days.	Only a short time, normally 1-24 hours. Then the JWT needs to be refreshed
Reset	Passwords need to be reset manually by the user	If the "client", eg. your mobile phone has a JWT this can be refreshed automatically. The user does not see this.
Security		Whenever a JWT is refreshed, then the backend is involved. The JWT could be revoked at any time.
More Security		The "client", eg. its IP-adress or a mobile device ID (which is quite hard to fake) can be encoded into the JWT. Any tampering with this can easily be detected in the backend.

Impartial