Storing JWT access token in httpOnly is NOT SECURE. It will still be be subjected to CSRF attacks.
Better to store the access token in a local variable (i.e Vuex, Redux). When the token is stored in a local variable, it helps protect the system from common attacks like CSRF and XSS. CSRF is prevented because the token isn't automatically sent with cookies but is instead sent as a header (bearer header) with each request. XSS is avoided because the token isn't stored in Session or LocalStorage.
For invalidation of a access tokens, If you setup a Redis lookup for your JWT authentication process. You basically defeat the propose of JWT in the first place.. just use Redis sessions at this point!?
I've always seen someone saying like this: Better to store the access token in a local variable
If the user refreshes the page (website) all the variable will reset to default so the jwt token that you stored in the variable (memory) is gone then the user will need to login again, So how is this the possible solution?
You really don't defeat the purpose, you have to properly consider the scale. You are storing only tokens that are invalidated, a tiny number, incredibly fast to look up - not a database of sessions to read and parse. You have to properly consider scale when you look at these things.
It may still be subject to CSRF attacks, though most types are naturally prevented, sure if you can trick the page into making a request the cookie will go with it. That's not so hard to defend against.
I can accept this as a work around to invalidate the tokens. But the drawbacks that were mentioned are still applicable:
Lets say I blocked a user "John Doe" from an admin dashboard.
lets say I changed the user role from admin to normal user.
lets say I want to know how many users are currently logged-in. (this we may use third party solutions to find out)
Well it's not so bad, you block the token, this requires an attempt at a refresh, the new token has the new permissions. Of course if you've banned the user, they can't refresh either.
JWT has use cases where it should contain permissions for authorization. It has many others where a trade off would not to be to do that.
These kinds of "Don't do this do that" comments just aren't very helpful, these tools have a reason to exist and a reason to work in the way they do. You have to keep an open mind and use the right tool for the right job.
If I have a system with 4.3 million users, of which between 100,000 and 1 million are roughly online at the same time, and users can purchase upgraded service elements then I'll use JWT for both. I'm not paying to manage a database and system with those concurrent sessions, they can live in a JWT and I'll use Redis to invalidate their current token if they buy an upgrade.
My current project, with around 10,000 b2b users each with fine-grained permissions, the JWT exists, but it only has an email and an ID in it. Used to look up a settings record - a session if you like. That's the right choice here.
So, use your brain each time and come up with the right answer. Try to avoid silver bullet answers.
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.
Storing JWT access token in httpOnly is NOT SECURE. It will still be be subjected to CSRF attacks.
Better to store the access token in a local variable (i.e Vuex, Redux). When the token is stored in a local variable, it helps protect the system from common attacks like CSRF and XSS. CSRF is prevented because the token isn't automatically sent with cookies but is instead sent as a header (bearer header) with each request. XSS is avoided because the token isn't stored in Session or LocalStorage.
For invalidation of a access tokens, If you setup a Redis lookup for your JWT authentication process. You basically defeat the propose of JWT in the first place.. just use Redis sessions at this point!?
I've always seen someone saying like this:
Better to store the access token in a local variableIf the user refreshes the page (website) all the variable will reset to default so the jwt token that you stored in the variable (memory) is gone then the user will need to login again, So how is this the possible solution?
You really don't defeat the purpose, you have to properly consider the scale. You are storing only tokens that are invalidated, a tiny number, incredibly fast to look up - not a database of sessions to read and parse. You have to properly consider scale when you look at these things.
It may still be subject to CSRF attacks, though most types are naturally prevented, sure if you can trick the page into making a request the cookie will go with it. That's not so hard to defend against.
I can accept this as a work around to invalidate the tokens. But the drawbacks that were mentioned are still applicable:
Lets say I blocked a user "John Doe" from an admin dashboard.
lets say I changed the user role from admin to normal user.
lets say I want to know how many users are currently logged-in. (this we may use third party solutions to find out)
Well it's not so bad, you block the token, this requires an attempt at a refresh, the new token has the new permissions. Of course if you've banned the user, they can't refresh either.
Do not use JWT for authorization.
Use JWT only for authentication.
JWT payload should be minimal because it will be re-send on each request. Stuffing it full of permission and roles is a bad idea.
JWT has use cases where it should contain permissions for authorization. It has many others where a trade off would not to be to do that.
These kinds of "Don't do this do that" comments just aren't very helpful, these tools have a reason to exist and a reason to work in the way they do. You have to keep an open mind and use the right tool for the right job.
If I have a system with 4.3 million users, of which between 100,000 and 1 million are roughly online at the same time, and users can purchase upgraded service elements then I'll use JWT for both. I'm not paying to manage a database and system with those concurrent sessions, they can live in a JWT and I'll use Redis to invalidate their current token if they buy an upgrade.
My current project, with around 10,000 b2b users each with fine-grained permissions, the JWT exists, but it only has an email and an ID in it. Used to look up a settings record - a session if you like. That's the right choice here.
So, use your brain each time and come up with the right answer. Try to avoid silver bullet answers.