Do I need to store the user data in the local storage after a user get authenticated. So that the next time the user won't need to login again. But it the case where I'm using a JWT authentication. Do I still need to store the user data and the token in the local storage? Because I've seen a lot of tutorial where both are stored, but I'm not able to see the utility of storing both in the local storage. Can't we verify the token when the user comes back and store the user data in the session storage?
When you are using JWT tokens you have to store them locally. For a REST API(probably you will use with JWT tokens) you have to send JWT tokens beside all of your requests. Because your USER API waits for a JWT token in a header or a post body. JWT tokens have information about a user to refer your user database E.g. userid, username. Do not store any user specific information in client side. A reference(userid) is enough to identify a user in your server.
If you use JWT tokens you HAVE TO store them manually-programmatically in your browser's local storage. But you can use cookies that are set by your server to make user logged in. In that case browser automatically stores your cookies and sends them with your further requests in a Cookie header.
Related
Im building an authentincation and authorization system in javacript using JWT token
basically when i login i store in httponly cookies:
JWT Token
JWT Refresh Token
user information (id, username, email)
JWT expiration (5 minutes from when it's generated)
When the JWT is still valid protected pages will do a remote check for user validity (i request an API passing the userId and the auth token as an authorization bearer)
the remote check can take some time (less than a second), but every protected page shows a loading spinner while checking; i was wondering how safe is assuming the user is logged in it the JWT is still valid (or the refresh token get a new JWT) and the cookie with the user data is present. No external requests involved, unless you need to refresh the JWT
i was wondering how safe is assuming the user is logged in it the JWT is still valid (or the refresh token get a new JWT) and the cookie with the user data is present
JWTs are not fit as a mechanism of managing sessions. A JWT has its own expiration time and this is regardless of the user's session. If you need to manage a user's session, just use mechanisms for sessions, and scrap the JWT.
I'm working on a project where I'm verifying admin and user from the backend. I have a database and there is a collection called admins. I stored my admin's email there and when a user will log in if the user's email is available in the database it will return isAdmin true or else it will return false. so that's how I can give the admin special access. But the problem is I'm storing my user information in the local storage so every time when the user opens the browser I can get his info without login him. so I have to also store isAdmin true or false in the local storage. If anyone edits the local storage he can get access to the admin panel. I want to know how can I make it more secure or how can I store isAdmin more securely so that no one can edit it from the client-side?
so ideally you shouldn't really solve these issues on frontend side of application but on API (backend, db, whatever you use). Only this that should be somehow saved on frontend (client) is user's token and with every request to API you should include this token and backend should be responsible for authorisation of request.
Simple example:
user logs in to api
api responds with auth token - 'abcd1234'
client saves this token to local storage / cookie
in next calls you include this token to request
GET /all-users { headers: { Authorisation: 'abcd1234' } }
API reads this token, decides if owner of this token is authorised to access these data
It's not this simple in real life, but you should understand a little.
And now solution to your problem - i suggest you to do none of this, but for school project its okay i guess
store your role in some hash so user doesn't know what is under the hash and can't simply guess admin hash
use some UUID instead of role - basically same as 1.
store your role in some global variable - so this way users can't see them in localStorage or cookies -- but its on client so its accessible to everyone in source code
I am working on an authentication system, implemented the front end using vuejs and back end with nodejs. User is able to register and login successfully. I am verifying user is logged in using jwt token. My problem is anyone can login by manipulating the localStorage jwt token value. Is there anyway to prevent it.
You should be using an asymmetric signature on your JWT token, and the private key should be available only to the server that creates the JWT. If this is the case, then it's highly unlikely that a user would be able to forge JWT claims.
Here's a step by step of how your server should prevent someone from changing their JWT info:
Your NodeJS server creates a new JWT using an encryption key (we'll call it secret-key) to create the signature, and it sends the token to the client.
The user decides they want admin access, so they change their permissions in their local JWT and send it to the server.
The NodeJS server re-signs the header and payload of the user's JWT using secret-key and compares that generated signature with the signature in the user's JWT. If they match, then nothing has changed about the user's JWT. If they don't match, then either the user changed something in the header or payload, or they tried re-signing the token with their own encryption key. Either way, your server can tell that the JWT isn't valid, and you can deny them access.
We are using oAuth token authentication app (server is Webapi2 with Identity, client is angular.js).
On login - the server issues a token for the user to use on every request.
we store this token using local storage.
The question is - how to store it on client if the user doesn't checks "Remember me" check box?
I looked at sessionStorage but there is no way to access it on other tab.
All I want is the client to forget the token when the browser window closes. how can I get this behavior - Do I have to use session Cookies for this scenario?
Storing the token in a cookie is the right way to go. In case you also to have the case when the user can disable cookies appending the token to the URL for each request would be the way to go.
Could I securely use local storage instead of cookies to store session credentials?
Would I need to store an encrypted hash??
EDIT: Would this be secure enough?
User logs in.
Server returns success message including salted bcrypt hash mixing userid, password, timestamp, and possibly ip address. This is saved in local storage.
On future connects this hash is sent, server assumes accountability as long as IP address hasn't changed, and time limit hasn't expired.
localstorage is just as vulnerable to being read by JavaScript as cookies are.
localstorage can be read using JavaScript from the same domain, if you control all the JS on the domain, then this shouldn't be a problem. But if any other code is executed (via injection for example, or if you share the domain with someone else), they will be able to access the storage data.
This is the same for cookies however, but typically the cookie is set to HTTPOnly so JavaScript cannot read it.
In either case, plain-text login information shouldn't be stored in either cookies or localstorage anyhow, as if someone does get hold of them, they can continuously make a new session for themselves.
You should encrypt an authenticated identifier (such as their user ID) along with the datetime of the session expiration, and then store this value in either a cookie or local storage. This token is then validated on each server call.
If you're going to be using local storage, why store user credentials or anything derived from them at all?
What I've been looking into doing is:
Upon successful login, generate a completely random string unrelated to user credentials and store that in the database, along with an expiry date. I would then pass that string to my js to be stored in local storage.
From then on, so long as that local storage credential matches the database one and the timeout has not expired, I automatically consider them logged in.
This way, there is no risk concerning the exposure of the user's credentials from local storage. However, with this temporary unique string essentially functioning as a sessionID, you will still to need to be aware of and take precautions against the risks associated with session hijacking.
In any case, my understanding is that local storage is as secure as the server behind your site is. By that I mean local storage is only accessible via scripts coming in through your own domain, so you're safe so long as the only front code running is your own.
You server shall generate some token - unique (for the server) piece of data that cannot be used to discover username/password. Only that token can be stored on user's machine in any form. Neither localStorage nor cookie are secure. So the same rules applied to them in this respect.
You should have some means to expire such token otherwise once stolen such token can be used instead of real credentials.
If you're going to use localStorage instead of cookies, you can make things more secure than cookies. That's because you don't need to send a session id to the server with each request, making it a bearer token. Instead, you can store a user secret on the client side in localStorage, and use it to sign your requests in addition to the corresponding public key being sent down and used as the session id. This way, no one on the server side or proxy can fake your requests.