JWT Tokens are decodable with Secret key

[sincerekamal]

Hello,
I love the concept of JWT. I have been using jwt-simple for almost 7-8 months. But my bad, I didn't figured out this problem till yesterday. The problem is that the auth tokens created by app server are decomposable(or disposable) from http://jwt.io/ .So how does it protects ?

[kentmw]

My understanding is that you can decode the payload and the header fairly easily - just a base64 encoding. That's not really the point of the jwt though. If you want something to be un-decodable, jwt isn't it (though, make sure you're still sending requests over https). It's the matter of verifying that the data inside the jwt was true to what was produced by the server.

Take for instance a jwt:
<header encoded>.<payload encoded>.<header and payload signed with a secret key>
Now, let's take the situation where someone changes the payload or header (let's say, to change the username or something). Because it's easy to regenerate the signature with the secret key, we can verify if anyone changed the payload by regenerating a signature from the new payload and comparing it to the provided signature. These will not match.

The main point is that jwt's are good for making sure that information that was once passed from the server to the client can be verified and unchanged when the client returns it. This makes it a good tool for API authentication keys.

[Kequc]

The payload of the jwt is unprotected, however the library validates that the content of the payload has not been tampered with. This means anyone can see the payload of the token, but on the server your application will know whether or not the content of the token has been changed.

Please correct me if I have misunderstood something.

[sethkoch]

The only way one can tamper with a JWT is if they know the secret stored on your server. At that point, they can do what they like with the JWT and it will pass validation.