Thanks for a great intro to this topic!
Please... for the love of god, never store the JWT in localStorage nor sessionStorage. It is vulnerable to XSS and a ton of other stuff. Store it in a secure cookie and let the server handle it without any client manipulation.
Anyway this is a great explanation!
I love the simplicity, thanks
Hey! This is the best explanation. Thank you!
how do we know the jwt received is right if we don't store it on the server side ? Do we encrypt it with our own private keys and decrypt them back afterwards?
Hey ! Pretty much, yes. Basically, once the server create the JWT, it'll "sign" it with a secured secret (an overcomplicated string, most likely). When your client send the JWT with the request, the server will "verify" the token, using the secret key you used to sign it.
Hey, you get to set the validity when implementing the token on your server.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
How to secure the JWT data? for example, in the session, user_id, shopping cart items, etc are stored on the server, while in JWT they are stored on the client, so the client may be able to change his user_id to 1 for example to gain super admin permissions later. This is a messy point to me!
JWT implementation already deals with that. Simply put, anyone can read (decode) the token. (the encoding scheme is Base64). However, it's impossible to forge a new valid token like your situation without the authenticating server knowing about it. The fake token on subsequent requests will be rejected immediately.
Even if a user tampers a token stored on client side,the server will compare the token sent with each subsequent request with it's secret key.
@goose97 @webdevopsfresher
_It is too late, but thank you for your reply. _
This may explain why such kinds of authentication need the HTTPS? I think, to add encryption as an additional security layer between the client and the server.