Bro, I completely understood this video. You are such a gem! I used to think JWT is not secure because anyone can tamper with it easily, even using the official JWT website 😂. But today, I learned that even if an attacker wants to change the payload (e.g., the database primary key of a user from a normal user to a superuser, like id=37), they can’t. When they send an HTTP request with this tampered JWT, the server rejects it with a 'tampered JWT' error. This happens because the combination of Header + "." + Payload now produces a different Base64-encoded string. After applying the hash function to this new string, it generates a different hash. However, with this tempered JWT token the signature is as it is. The Signature decryption still contains the old hash, as the payload wasn't changed for the normal user. 👌👌👌👌🗝️ The creator of JWT is truly a legend!
Hello, Thank you for the detailed explanation; it is really helpful! I have a question: how does the receiver decrypt the message if only the server has the private key?
Hi, server encrypts the signature using the private key. Receiver decrypts the signature using the public key. Any one can decrypt a signature, but only server can encrypt a signature. Hope this helps, cheers 👍🙏
@@learningsoftwareskills Thank you for your input! However, I think there might be a misunderstanding. In public key cryptography, the public key is used for encryption, while the private key is used for decryption. When it comes to signatures, the server creates the signature by encrypting it with its private key, and the receiver can verify it using the server's public key. This ensures authenticity. Let me know if you'd like to discuss it further! Cheers! 👍
Great explanation. I have a question does the public key should be present in the JWT, or it should be already be present on the client side for verification.
@@learningsoftwareskills I think you didn't understand his question. The client should fetch the public key from the authentication server. If the public key came in the JWT, someone could tamper the JWT by replacing the public key with a new one. AWS Cognito for example provides a URL where the public key can be obtained.
@@brunobkpzica4598 oooh nice recommendation for aws cognito, ill use it for fetching a certificate x509, as far as i know this is more secure than public key because theres a more specific way to validate the token with a issuer and subject info and also with expiration, since public key does have these features
Finally someone that really explains how the validation is done - thanks, very clear
Thank you for the amazing feedback 👍🙏
Thanks! It was really nice explanation :) best I found in internet so far about this in form of video :)
Thank you for the amazing feedback and support 👍
One of the best explanations I found about JWT in the internet. Thank you for the video
Thanks a lot for the amazing feedback 👍🙏
i second that
It was very helpful. thank you.
Nice one🎉 thanks for the video.
Thanks for the encouraging feedback👍
Couldn't have done it better. Well done.
Thank you for the amazing feedback 🙏👍
Excellent Video on JWT token validation! Keep the good work going!
Thank you👍🙏
Really very good explanation. It helped me to understand what JWT is and how it works. Thanks a lot
You are welcome 🙏👍
Very well explained!! Thanks
I am glad you liked it 👍
Too good sir, really helpful, may god bless u
Thank you 👍🙏
Really detailed explanation about JWT.
Thank you for this video!
Hi, Glad you liked it! Thanks 🙏😊
Too good explanation... Keep up the good work!!!!!
Thank you 🙏👍
Good Explanation
Thank you very much 👍
Best explaination ever, very concise :D
@@SoyJavero thank you 🙏👍
Thank you. I wish i had seen this video before a job interview i had last week.
Thank you very much for ur amazing feedback 👍🙏
next time you'll get it right :D
One of the best explanations thank you..
Thank you for the amazing feedback 👍🙏
Perfect explanation, thanks
Thank you for the amazing feedback 👍🙏
Bro even bytebytego was not able to explain it like you did , good job.
Thanks a lot bro 👍🙏
what a great video thank you, youre a legend
Hi thanks a lot for the encouraging feedback👍🙏
@@learningsoftwareskills I managed to implement it in a language i had no experience in. thanks for this video
excellent! Thank you so much!!!
@@rryann088 thank you for the amazing feedback 👍🙏
Very nice explanation 😃 kudos👏 first I understand deeply
Thank you very much 🙏👍
excellent and precise, thank you
You are welcome 👍🙏
Very well explained
Thank you 🙏👍
Awesome explanation buddy
Thanks buddy
superb explanation
Thank you 🙏
Bro, I completely understood this video. You are such a gem! I used to think JWT is not secure because anyone can tamper with it easily, even using the official JWT website 😂.
But today, I learned that even if an attacker wants to change the payload (e.g., the database primary key of a user from a normal user to a superuser, like id=37), they can’t. When they send an HTTP request with this tampered JWT, the server rejects it with a 'tampered JWT' error.
This happens because the combination of Header + "." + Payload now produces a different Base64-encoded string. After applying the hash function to this new string, it generates a different hash.
However, with this tempered JWT token the signature is as it is.
The Signature decryption still contains the old hash, as the payload wasn't changed for the normal user.
👌👌👌👌🗝️ The creator of JWT is truly a legend!
Yes
Precise
@@Mayank-pk2oj thank you 👍🙏
Hello,
Thank you for the detailed explanation; it is really helpful!
I have a question: how does the receiver decrypt the message if only the server has the private key?
Hi, server encrypts the signature using the private key. Receiver decrypts the signature using the public key.
Any one can decrypt a signature, but only server can encrypt a signature.
Hope this helps, cheers 👍🙏
@@learningsoftwareskills Thank you for your input! However, I think there might be a misunderstanding. In public key cryptography, the public key is used for encryption, while the private key is used for decryption. When it comes to signatures, the server creates the signature by encrypting it with its private key, and the receiver can verify it using the server's public key. This ensures authenticity. Let me know if you'd like to discuss it further! Cheers! 👍
Great explanation.
I have a question does the public key should be present in the JWT, or it should be already be present on the client side for verification.
Hi, public key should be present in jwt. This is required for validating the hash
Hope this helps, cheers 👍
@@learningsoftwareskills I think you didn't understand his question. The client should fetch the public key from the authentication server. If the public key came in the JWT, someone could tamper the JWT by replacing the public key with a new one. AWS Cognito for example provides a URL where the public key can be obtained.
@@brunobkpzica4598 hi, you are right. I was wrong about the public key. The public key should be fetched from the server. Thanks 👍
@@adityathakur3748 sorry the reply was wrong. The public key should be fetched from the issuing server for validating the signature.
@@brunobkpzica4598 oooh nice recommendation for aws cognito, ill use it for fetching a certificate x509, as far as i know this is more secure than public key because theres a more specific way to validate the token with a issuer and subject info and also with expiration, since public key does have these features