After spending some time reading about authentication and noticing it is pretty hard to do it well, I have decided to use firebase-authentication to authenticate my users in my vue app.
I'm listing the technologies and flow I use in this app to show each part interaction and clear things up:
I use Vue for my client javascript client
The client log-in users using firebase-authentication.
When user log-in, a call to a node.js rest api is done and a json is retrieved with its user data.
When the data is retrieved by the client, the app shows some parts and hides other depending on user privileges
So, in my Vue application I show a custom login form and use it to authenticate users through firebase. After the user log-in, I retrieve some data from my own server (just a json with different user config values) that defines how the user can interact with the app (For example, what he can or can't do in my app).
How can I retrieve this information and use it in my client app in a secure way?. I mean, as an example, say I have a piece of information in that JSON that defines if the user is a regular or admin user. How can I avoid users to modify the response from the server and elevate privileges?
There isn't anything you can do to prevent client side DOM manipulation. If it's accessible via JavaScript, it's accessible to the user. It's up to you to implement your application in such a way that sensitive information and/or functionality is not dependent on client side security (if such a thing truly exists).
What you can do is prevent unauthorized access on the server. This is the purpose of defining scopes, ACLs, etc. If a savvy user does modify the response data and, say, change their role from user to admin, your response should not contain anything meant for admin users only. Rather, that information should only be accessible after making a successful API call where your server code has authenticated/authorized the request.
Never trust the client when it comes to security. That must be done on the server.
Related
I am using my building journey to learn web development. I'm using nodejs, reactjs, mongodb, axios and expressjs.
Currently, I'm storing basic user details such username, id, role,email in the local storage. I could store other things as I continue.
However, along the line, I felt that storing something like role in the localstorage could be problematic since anyone can edit their localstorage. This means, user can easily edit their local storage and change their role to admin to have access to what admin has access to.
I decided to visit some known websites like Upwork, etc, I checked my localstorage and I noticed that they didn't store information such as username, email, role, etc.
As someone new in this field, where do you think is best to store information such as the above I mentioned, especially data that can grant access and change access privileges of any user? I don't think localstorage is best for this at all.
Also, while inspecting the browser developer tool, I noticed that whatever one passed from the response from backend is also seen under the response section in the web developer tool.
Is that response section accessible by Javascript? Or it is already encrypted by expressjs?
There are two concepts here which are important to understand: Authentication and Authorization.
Authentication is the process by which the server will validate that the user says who they say they are. The most common example of authentication is username and password.
Authorization is the process by which the server will validate the user can perform the action they want to perform. Once the user is authenticated, they will usually look up the user in a database and see if the user as the rights to do this (in your example, once such right could be admin).
For your example application, you could probably do something simple like store the username, a hash of the password and the user role in a table in your database. That would probably be good enough for your learning. When a user is trying to access something, look up the role in the table and if they don't have permissions to, return a 403 Forbidden
But you are just scratching the surface of the topic. For example, you said that applications do not store roles on the client side, but interestingly if you're using something like Json Web Tokens, this information will be on the client-side. In this flow, you authenticate to your service, you get a token that contains your role (admin in your example) and a signature. The signature is used to validate that the token was emitted by the service, meaning that the role it contains can be relied on. So when your application makes a request to your service, your service will only need to validate the signature.
I was once in your shoes, trying to figure out what to use when, when working with the same tech stack as yours. Let me tell you now what I use-
Decide what do I want(if it is a small application that needs to be built rapidly with all functionality I use sessions ( nodejs provides an excellent library known as express-sessions ), if I want a detailed fast app, I use JWT.
When you want to store things user settings of volume, light-mode dark mode, you can use simple local data storage.
If you are receiving data on the frontend side and want to use it there, you can use state-management frameworks like zustand, redux, or any others.
Further detail on the question -> you can modify what you store in the session like username, email-id, and all that, and as more data is needed you can request from the database once the user is verified.
If you have more specific questions to ask, feel free to fire on me, I will try my best.
Upvote if it gave you some insight on topic.
Never store important information on localstorage. Your intuition of it can be changed or it can be accessed by someone else is correct. And even if you store some data (such as jwt tokens) never trust your front end and validate it with the backend server for data retrieval.
In your case you can use session storage or cache storage depending on how to store the data that you need
I am making an app that returns a music playlist based on a user’s age. The user does not need need to log in to their account; they only need to provide their age. I also have no need for a database, so I decided that I want to make the application front-end only.
In order to make requests to Spotify’s API, I need an access token which I get via client credentials, because the user doesn't need to login using that flow. However, the script I used to get the access token must be run from the server-side, which I discovered here: Access-Control-Allow-Origin denied spotify api.
The alternative solution is to use the implicit grant flow, which will allow the script to be run client-side but will require a user to log in. So, both the client-credentials and implicit grant flow don't solve my problem.
How can my web app get an access token so that I don't need to implement a server-side or have the user log in?
Although the idea is different, I want to do something like this person is doing # http://sixdegreesofkanyewest.com/. No one logs in, yet he is able to get an access token and send api requests on their behalf. And I don't really see why that website would require a database either.
If I do end up having to develop a back-end, then I would be able to use client-credential flow. But, how would my back-end send the access token to my front-end without a DB?
Any help is appreciated. Thank you!
Implicit grant is recommended for javascript based application, who can not keep secrets safe. So you may have to strike out this option.
Having a server page, (hope the credentials kept safe in your server), then server app sending the request for token and rendering the page..
I guess that is what the http://sixdegreesofkanyewest.com/ will be doing.
So your option is server pages application. or an intermediate API call to get the access token for you and continue your application logics
I wanted to check with you guys if my API Key and user Authentication scheme makes sense or not. My server side code is in PHP and the Database is MySQL. This is the scheme I have in mind:
I am implementing a REST API in a backend server that will be called by a Mobile App (for now). At this point, I only want known Mobile Apps to connect to this API. So I am using a one-time API Key that has been given to the Mobile App during installation. Every request from the App passes the API Key that my API checks before going further. This Key is stored in a Database table. This completes my API Key checking and seems to allow only known Apps from calling my APIs.
Next, I also have certain services after calling the API which only authenticated users are supposed to get access to. For this, the Mobile App logs in with a Username and password which is authenticated in the User table of my Database. If it passes, the server generates a User Token and passes it to the Mobile App. The User Token is also saved in the User table against that User. All subsequent requests from the App (which requires user authentication) passes this User Token which is checked in the User table in the Database for User Authentication. If the Mobile App logs out, this User Token is deleted from the User table. I also have provision to add "TimeToExpire" for this User Token which I will implement later.
I would be really grateful if you guys could tell me the following:
Does the above structure makes sense for App Authentication and User Authentication?
I am a little lost as to what will happen if I ever need to change the API Key (for whatever reason). Not sure how that will be sent to all the Apps. Google Messaging seems like one possible way to handle that.
For the App Authentication, does it make sense to keep the API Key in a Memcached object? Since all requests from the Apps are authenticated, I don't want to go to the DB everytime. And pros/cons?
Along the same lines, does it also make sense to have the User Token in a Memcached object as well? Pros/cons?
How does one handle authentication (local and Facebook, for example) using passport.js, through a RESTful API instead of through a web interface?
Specific concerns are handling the passing of data from callbacks to a RESTful response (JSON) vs using a typical res.send({ data: req.data }), setting up an initial /login endpoint which redirects to Facebook (/login cannot be accessed via AJAX, because it is not a JSON response - it is a redirect to Facebook with a callback).
I've found https://github.com/halrobertson/test-restify-passport-facebook, but I'm having trouble understanding it.
Furthermore, how does passport.js store the auth credentials? The server (or is it service?) is backed by MongoDB, and I'd expect credentials (login & salted hash of pw) to be stored there, but I don't know if passport.js has this type of capability.
There are many questions asked here, and it seems that even though the questions are asked in the context of Node and passport.js the real questions are more about workflow than how to do this with a particular technology.
Let's use #Keith example setup, modified a bit for added security:
Web server at https://example.com serves a single page Javascript client app
RESTful web service at https://example.com/api provides server support to rich client app
Server implemented in Node and passport.js.
Server has a database (any kind) with a "users" table.
Username/password and Facebook Connect are offered as authentication options
Rich client makes REST requests into https://example.com/api
There may be other clients (phone apps, for example) that use the web service at https://example.com/api but do not know about the web server at https://example.com.
Note that I'm using secure HTTP. This is in my opinion a must for any service that is available in the open, since sensitive information like passwords and authorization tokens are passing between client and server.
Username/password authentication
Let's look at how plain old authentication works first.
The user connects to https://example.com
The server serves a rich Javascript application which renders the initial page. Somehwere in the page there is a login form.
Many of the sections of this single page app haven't been populated with data due to the user not being logged in. All these sections have an event listener on a "login" event. All this is client side stuff, the server does not know of these events.
User enters his/her login and password and hits the submit button, which triggers a Javascript handler to record the username and password in client side variables. Then this handler triggers the "login" event. Again, this is all client side action, credentials were not sent to the server yet.
The listeners of the "login" event are invoked. Each of these now needs to send one or more requests to the RESTful API at https://example.com/api to obtain the user specific data to render on the page. Every single request they send to the web service will include the username and password, possibly in the form of HTTP Basic authentication, since the service being RESTful isn't allowed to maintain client state from one request to the next. Since the web service is on secure HTTP the password is safely encrypted during transit.
The web service at https://example.com/api receives a bunch of individual requests, each with authentication information. The username and password in each request is checked against the user database and if found correct the requested function executes and data is returned to the client in JSON format. If username and password do not match an error is sent to the client in the form of a 401 HTTP error code.
Instead of forcing clients to send username and password with every request you can have a "get_access_token" function in your RESTful service that takes the username and password and responds with a token, which is some sort of cryptographic hash that is unique and has some expiration date associated with it. These tokens are stored in the database with each user. Then the client sends the access token in subsequent requests. The access token will then be validated against the database instead of the username and password.
Non browser client applications like phone apps do the same as above, they ask user to enter his/her credentials, then send them (or an access token generated from them) with every request to the web service.
The important take away point from this example is that RESTful web services require authentication with every request.
An additional layer of security in this scenario would add client application authorization in addition to the user authentication. For example, if you have the web client, iOS and Android apps all using the web service you may want the server to know which of the three the client of a given request is, regardless of who the authenticated user is. This can enable your web service to restrict certain functions to specific clients. For this you could use API keys and secrets, see this answer for some ideas on that.
Facebook authentication
The workflow above does not work for Facebook connect because the login via Facebook has a third party, Facebook itself. The login procedure requires the user to be redirected to Facebook's website where credentials are entered outside of our control.
So let's see how things change:.
The user connects to https://example.com
The server serves a rich Javascript application which renders the initial page. Somehwere in the page there is a login form that includes a "Login with Facebook" button.
The user clicks the "Login with Facebook" button, which is just a link that redirects to (for example) https://example.com/auth/facebook.
The https://example.com/auth/facebook route is handled by passport.js (see the documentation)
All the user sees is that the page changes and now they are in a Facebook hosted page where they need to login and authorize our web application. This is completely outside of our control.
The user logs in to Facebook and gives permission to our application, so Facebook now redirects back to the callback URL that we configured in the passport.js setup, which following the example in the documentation is https://example.com/auth/facebook/callback
The passport.js handler for the https://example.com/auth/facebook/callback route will invoke the callback function that receives the Facebook access token and some user information from Facebook, including the user's email address.
With the email we can locate the user in our database and store the Facebook access token with it.
The last thing you do in the Facebook callback is to redirect back to the rich client application, but this time we need to pass the username and the access token to the client so that it can use them. This can be done in a number of ways. For example, Javascript variables can be added to the page through a server-side template engine, or else a cookie can be returned with this information. (thanks to #RyanKimber for pointing out the security issues with passing this data in the URL, as I initially suggested).
So now we start the single page app one more time, but the client has the username and the access token.
The client application can trigger the "login" event immediately and let the different parts of the application request the information that they need from the web service.
All the requests sent to https://example.com/api will include the Facebook access token for authentication, or the application's own access token generated from Facebook's token via a "get_access_token" function in the REST API.
The non-browser apps have it a bit more difficult here, because OAuth requires a web browser for logging in. To login from a phone or desktop app you will need to start a browser to do the redirect to Facebook, and even worse, you need a way for the browser to pass the Facebook access token back to the application via some mechanism.
I hope this answers most of the questions. Of course you can replace Facebook with Twitter, Google, or any other OAuth based authentication service.
I'd be interested to know if someone has a simpler way to deal with this.
I greatly appreciate #Miguel's explanation with the complete flow in each cases, but I'd like to add some on the Facebook Authentication part.
Facebook provides a Javascript SDK which you can use to get the access token on client-end directly, which is then passed to the server and used to further pull all the user information from Facebook. So you don't need any re-directs basically.
Moreover, you can use the same API end-point for mobile applications as well. Just use the Android / iOS SDK for Facebook, obtain the Facebook access_token on the client end and pass it to the server.
Regarding the stateless nature as explained, when get_access_token is used to generate a token and passed to the client, this token is also stored on the server. So it's as good as a session token and I believe this makes it stateful ?
Just my 2 cents..
Here is an awesome article I found that can help you authenticate with:
Facebook
Twitter
Google
Local Auth
Easy Node Authentication: Setup and Local
I've written a web application that interfaces to an API, in a different domain.
This API requests a username and password for certain calls (involving POST, e.g. to upload a photo to the API). For these calls the API uses https.
Is there a way I can store the username and password within the web app, so the user doesn't have to log in repeatedly each time they upload a photo?
Here's what I can think of:
The obvious way is to stick both in a cookie, but clearly that's a security hole, whether plaintext or hashed.
If it were a secure website, I could use a session ID: could I persuade the API owners to allow session IDs, or would that be impossible across domains?
Perhaps I simply have to ask the user to re-enter their username and password each time they make an API call.
Thanks!
If I understand your architecture correctly, your users are sending the API calls to a service running in a different domain. You are not a man-in-the-middle for this request, you are only providing the interface e.g. as a form-field in your web application. The user can send the API calls without you even knowing that he did.
In that case there is no way to implement this without storing some kind of authentication information in the browser (cookie, form-field, etc.) or have your users enter them for each request. They must come from somewhere and your server is not involved in the request.
What you can do is changing the architecture and start playing man-in-the-middle, like a proxy. Instead of just providing the interface, let the users send their requests to your web application instead of communicating with the service directly. Your web application adds the credentials and forwards the request to the service. The answer of the service will be sent to your web application, which can redirect it again to the user.
In this scenario your web application is responsible for authentication. Your web application adds the credentials to a request if the user sending the request was identified and has the required permissions. The credentials for the service are only passed from your web application to the service, they even can be kept hidden from the user himself.
Such a change has several implications of course. The load on your web application will increase and the logic will become more complex. Those trade offs must be considered.