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
Related
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.
I'm completing an unfinished project someone else worked on and trying work out how to create a secure page for an API driven front-end.
When a user logs in successfully, a local storage variable is being created that contains user information, including user token and user secret.
I require a secure dashboard page that calls secure API's.
Am I correct in the following approach :
When secure page loads, a JS routine is executed which checks local storage for user token. Can this be a simple check for user token existence ?
If token present then the secure API's are called using the secret key. The api then returns sensitive data to populate table.
Will this work?
UPDATE:
Both server and client will run under https. As data in encrypted, secret token can be stored on client. Front-End is static html/JS making API calls for sensitive data using secret (only available to authenticated user). None of the user data is hardcoded to F/E but instead is referenced from local storage. Then tokens can be used securely to make further API calls as required for sensitive data. So basically, no-one else should be able to get to sensitive data as cookie/storage is limited to client machine and will expire anyway.
I was looking for a blog/tutorial to confirm my understanding as above.
Thanks
This approach seems OK. I don't know your exact requirements, but I would suggest using a cookie instead of localstorage, given that the token is sensitive information and should not be stored for a long time if it doesn't have to.
If the user has it's personal permanent access token go with localstorage. If the token is fetched from an auth-server upon login, use cookies instead.
I'm making a login page and I've found that JWT tokens are preferred over sessions but I don't understand what to do with a token.
I send user and password uncrypted with ajax to server and validate the user in a php file which then returns a JWT.
What should I put in my JWT? Do I only check for a token to know if the user is logged in or do I process it somehow to check if it's the right token? If so, how?
So far I've seen examples on client side where you only check if token exists but why should I have hashed data as token instead of a 1 or a 0. I don't get the advantages of this method.
EDIT: Should I both request a JWT token which I store in session storage and store what the user types in the log in field also in session storage and then compare them with eachother every time the user reloads the page?
Looks like we need basics of how JWT works here:
The client sends username/password to the server using ajax.
The server checks username/password and if they are valid, creates an encrypted token, which the only server can read and understand.
Server takes into account various fields (also known as "Claims") like "iss" (token issuer) and "Sub" (Subject of token), whole list here.
We can custom fields like user-id which can be used later while validating token.
Server sends token back to client through response. Client saves this token in local storage or some variable.
With each further request, client sends this token as header.
Server examines and validates this token, gets require info from this token like user-id and responds to the user appropriately if valid. Token may also contain expiry date/time, so after a certain time, the server may choose to refuse to serve a client.
While this may not directly answer your question, it clarifies basic workflow of GWT.
I am using the Facebook login as an authentication for my PhoneGap application - once a user logs in, their data is retrieved from my database to display information. I am not using the SDK for any other purpose.
I have the Facebook auto login working fine - it retrieves an authResponse and my Facebook information. Since the access token changes with each login, what can I use to store locally and in my database to authenticate the user on my server for future logins?
Here is a flow that I think could work...
User sees logs in screen and enters Facebook credentials
Facebook securely validates and returns user information & access token
The app uses localStorage to store user email and access token
For future autologin, the localStorage values are used as email/password
I feel like this cannot be the correct answer, however.
I figured out a solution - I was confused about storing passwords on my database to fetch user information. Rather, these are the correct steps:
Use Facebook SDK to handle the login and retrieve the authResponse
Update the user table in my database with the temporary access token and retrieve user's information
For every POST or GET the user wishes to perform, I will match the FB.getLoginStatus() results from the database's access token (the check will be done server side)
If the tokens match, perform requests. Otherwise, force the user to login again.
I'm developing a web app on the MEAN stack (MongoDB, Express, AngularJS, and node.js). I'm developing a login system, and will also have some of the Angular routes protected so that only logged-in users can access them. I'm trying to think of the best way to approach the architecture of this.
I'm thinking of the current workflow:
User logs in via AngularJS form, which sends an http POST to an Express endpoint. The endpoint validates the user against the database, and responds with an OAuth token as well as a cookie. Both are stored in the mongo database for later validation.
Once AngularJS receives the login response, it stores the received cookie using ng-cookies, and stores the OAuth token in a User service.
Every time the route changes in AngularJS now, the User service is used to make sure that the cookie is still legitimate by comparing it to cookies in the mongo database (this would be an API call using Angular's resolve... would this create a noticeable lag?)
When a user clicks "log out" or the cookie expires, the cookie and OAuth token are both deleted from the database and will no longer be valid.
Does this approach make sense? Is it secure, and will it be relatively efficient/quick in execution?
I ended up combining my original workflow with Express's auth example, seen here. It is as follows:
When user initially loads the app, an http call is made to an Express endpoint that checks if a session exists already for the user. If so, the user is stored in $rootScope and considered logged in.
Any time the AngularJS route changes, the same endpoint is accessed. Route protection was specified in a way similar to that described here. If the endpoint ever returns that no session exists, $rootScope.user is unset (if it needs to be), and the user is redirected to the login page.
When the login form is processed, it posts to an Express endpoint. The endpoint retrieves the user from the mongoDB (if it exists), and attempts to hash the password. If it's a match, the user's session is set, stored in the mongo DB, and the endpoint returns the user object (used to store in the $rootScope as previously mentioned).
Any time any further endpoints are accessed, the functions are first passed through the restrict function which ensures that a session exists before sending any data to the client. It returns a 401 if no session exists, which is then handled on the Angular side using this HTTP interceptor to unset $rootScope.user and redirect to the login screen.
When the user clicks "log out" on the Angular side, the session is unset and deleted from the mongo DB, $rootScope.user is set to null, and the user is redirected back to the front page.