I am trying to setup a login process for firebase. I am going to be using client side user creation (because apparently firebase only allows client side user creation), and here's what my workflow looks like:
User signs up through email and password
Service creates an entry at /users/$uid, as well as a couple others (ie /table1/$uid, /table2/$uid)
User can write to database at path /users/$uid, /table1/$uid, etc where $uid = the current logged in user (this is done via rules)
However, for number 2, I want to create the entry /users/$uid, but I dont want the user to have access to that at all. Is there any way to do this? One option I thought of was having a service account running with all r/w permissions on a node server to create those tables, but how would I call that server method if I'm doing all of the auth client side?
After step #1,
Your client code can get a Firebase token for the current login user via firebase.user.getToken()
Your client app sends the token to your node server
The node server validates the token using Firebase server SDK
The server extracts user id from token.uid.
Now you can continue step #2 to create table for the user.
Related
I have setup my firebase authentication on the server.js file and have used socket.io to transfer data and trigger change when user signs in and signs out. However, I was wondering how I can login through the client and not the server?
The reason is because when I login through the server, there is only one user that can be authenticated (Only one user to login at a time). Hence, if I login through client, many users can login.
Thanks.
I'm using AccountKit for phone sign up right now in our mobile app. As AccountKit will be deprecated soon so we are migrating with firebase phone sign up.
I have set up a new user/Sign-up flow but still confused about old users when they log-in again using a new sign-in method(Firebase).
Current Login Process:
Client request with the access token.
Server request to account kit with an access token and get user data with UID
By this UID I check in current database user present or not.
Problem:
When old user tries to sign in through firebase then I'll get different UID(UID of firebase) which is not present in my database so it will consider it as a new user.
Backend: Node js
Can someone help me what would be the best approach to migrate?
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.
I'm using a web API that receives http get requests and return json data coming from a mySQL database.
The http url return all users (http://localhost:3000/api/users)
The data arrives like this:
How can I authenticate users with Angular 2+ using this data?
Store the list of "allUsers" in local storage. However you shouldn't return the user set in 1st place.
Then take user credential from login page, and compare it to data being present in the 'allUsers' collection.
Angular guards can allow authorization once you have identified a user as valid. For that, you need to send the logged in user details to security database and identify correct roles. But first you must authenticate as above.
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?