In the world of web development, security is paramount. One of the most popular methods for securing web applications is JSON Web Token (JWT) authe...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
Good primer but a bit was left out that would probably be helpful for someone thinking about JWT vs say, OAUTH2 or an API token. In particular I'd add that first, you should NEVER store JWT tokens in local storage. The server should always use httpOnly flag, and it should only be done over SSL/TLS. "But then the client cant read the token data and get info like user id, name, etc from the token". Yup. That info should be returned as part of the body response on login when the token is also returned. Any details like user name, email, etc that need to be used in the app, should only come back on login as the response body. This ensures that nobody on the client or in between client and server (say.. an extension for example ) can access the token and use it for nefarious purposes.
The second thing I'd add is that you almost always want a refresh token AND an access token generated. The refresh token is long lived.. maybe 30 days, or just 1 day, if your domain requires daily logins. The access token is short lived. I'd argue 30 minutes max, but I typically have mine at 5 minutes. The access token contains the details like RBAC, etc.. that the server side uses to determine if the request being made is allowed. It is also used to enable invalidation of a user. For example, a user is an employee.. who got fired but had logged in 1 minute prior. Well now they are angry and they can wreak havoc for as long as that access token allows them to (assuming their "role" in the token allows them to do nefarious things). But HR invalidates their user account. When the access token expires in a few minutes.. the refresh token is used to look up their user account (e.g. similar to a login) but perhaps its in a Redis table or some other manner in which a user account is used. The point is, at that point the account is discovered to be disabled, so the refresh token is now invalidated and a 401 is returned. The client side will then redirect to a login page again, and when they try to log in.. no longer can do so. This method avoids having to have some sort of server side Redis blacklist DB to keep track of all users, etc.
If it's properly done, implementing JWT is not hard.
What might be worth mentioning is that besides validating if a token is right and valid, you should have a system to be able to deactivate tokens.
You can implement this by using redis. Set the ttl of the token in redis. After that, before the server verify the token, you must check the token if exist in the redis, then proceed to the token validation.
Annnd, bravo for reinventing sessions.
Exactly!
Yes!
In my experience JWT works fine in a close, trusted system where a token could live like only for a few seconds or even minutes and each node is able to verify the tokens validity by checking the signature and using only the permissions defined in the token.
For a client-server connection where the client is outside of this trusted system (e.g. a mobile app, a browser) there should be a session-based authorization. A session can store a refresh token on the server side and each request from the client should go through an API gateway or whatever you call, which checks the session's validity and asks for a short lived access token with the refresh token and forwards the request with the token to the proper service.
The benefit of this combination is that the app can control the active sessions (e.g. you can list your logged in devices, geolocation in Google Accounts and even destroy a session if you want without even touching the device itself), you can control the length of a session independently of the refresh/access token's lifespan, you can use short lived access tokens which can be verified by the services.
If you put the token to a HTTP-only cookie, you basically use the token as a session ID, but without the benefits of a session. Yes, you can blacklist a token, but in this case your service nodes have to call back to the auth service to check if it is blacklisted or not.
JWT coupled with Zero Trust Access developers.cloudflare.com/cloudfla... is the way forward.
Thanks
Thanks!
Well explained thank you. My understanding is that today I should not be implementing my own authentication system. For example I would use AWS Cognito. I'm guessing what you've described is what is done in Cognito too. I would be interested in exploring further. JWT renewals. How to store on client. And how services like Cognito use it.
Thanks!
I disagree with this approach to JWT because the token is not secure and hidden from JS. The way I do it is to store it in an httponly cookie so that nothing can touch it. You will still need to persist some data to determine if a person is logged in but I think that should be just user ID and user's role. Authorization would just happen server side with the JWT from the cookie; the persisted data on the front end would just be to restrict views
Congratulations, great article! I have one doubt: What is the best way to store a JWT in Client Side?
You can prefer to use cookie and set credentials via Cookie on browser.
Failed to mention that JWT tokens are only secure as long as you can invalidate them, but if you have to invalidate them then you need some database to store tokens in, which renders JWT pointless for many practical applications.
Long lived JWT - need to store information about invalidated tokens === basically the same as sessions but overly complicated for the purpose.
Short lived JWT - only useful to closed networks, e.g. servers talking to each other. For frontend, do you want to logout users every 5 seconds?
One of the most nicest articles I have ever read!
A clear, concise and to the point explanation.
Thank you!
Thanks!
This is insightful...
You didn't do much.. just easy and straightforward
I wish the part with using the JWT after it is expired, particularly the refresh token concept
You have my respect "Stark".
Another AI-generated article:
Good article! There are some security and scaling issues to be aware of with JWTs as this article from Redis describes. redis.io/blog/json-web-tokens-jwt-...
Yeah!
Can this be implemented in Django?
I think Yes!