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

User · Answer

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  quot Have the contents of this token been manipulated quot   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   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   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    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

User · Answer

Ref - JWT Structure and Security 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  quot Man in the Middle quot  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

User · Answer

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

User · Answer

I would suggest in taking a look into JWE using special algorithms which is not present in jwt io to decrypt  Reference link  https   www npmjs com package node-webtokens  jwt generate  PBES2-HS512 A256KW    A256GCM   payload  pwd   error  token    gt      jwt parse token  verify pwd   error  parsedToken    gt           other statements             This answer may be too late or you might have already found out the way  but still  I felt it would be helpful for you and others as well   A simple example which I have created  https   github com hansiemithun jwe-example

User · Answer

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

User · Answer

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 hashes 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

User · Answer

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

[security] If you can decode JWT, how are they secure?

Examples related to security

Examples related to jwt

Examples related to express-jwt