I want to add a new data to firebase authentication which has data like displayname, phone number, image. But i want to add more such gender, birthday and more. is it possible to add new?
There is no way to add arbitrary additional data to Firebase Authentication user profiles. If you want that, consider using the Firebase Realtime Database (or Cloud Firestore) for storing the additional information.
This approach has been covered in quite a few questions in the past, so I'll link you to those:
Firebase: setting additional user properties
Add extra User Information with firebase
How do I link each user to their data in Firebase?
Swift & Firebase - How to store more user data other than email and password?
Store additional information during registration with Firebase in Android
How to add additional information to firebase.auth()
Since a few weeks ago you can add small bits of information to the Firebase Authentication user profile. While this might sound like what you need, it is explicitly not meant for storing user metadata such as you need. Instead this is intended for storing so-called claims: properties about the user that you then access in the security rules. See the documentation for setting custom claims.
I had the same problem when introducing user roles for authorization in my React with Firebase application. Somehow I wanted to be able to pass a roles property to the authenticated user, but found myself again in Firebase's restrictive framework of doing it their way.
I found a way around it by (1) managing users myself in the Firebase database and (2) merging the authenticated user with the database user when the application loads. Then I am able to add additional user properties (e.g. roles) to my database user, because it will be merged with the authenticated user anyway.
If you are interested in this approach, checkout this tutorial.
Related
I am currently using firebase to make an ionic app. I am using firebase simple login for social auth (facebook, twitter, email & password). The auth works perfectly, it $broadcasts the authed user. However it doesn't seem to create a user in the actual firebase db. I was wondering how I can get the users that have been authed using my app.
For most of the authentication protocols it supports, Firebase doesn't store user data anywhere. Even for the protocols where it does store data (I only know of email+password doing this), it stores this information in a place that your application can't access (though you can find those users in the dashboard of your Firebase).
To quote the Firebase documentation:
It does not store profile or user state in your Firebase. To persist user data you must save it to your Firebase.
What most applications end up doing, is keeping a list of users inside their Firebase that they manage themselves. So when a user first authenticates with the application, it creates a node under /users/<uid> that contains the information for that user.
See this section of the Firebase documentation that describes storing user data.
Firebase does not store profile or user state in your Firebase instance. To persist user data you must save it to your Firebase.
Firebase provides multiple authentications services
Using existing social login providers such Facebook, Twitter, Google, and GitHub. Using these services provides an option for your users to access your application without creating a new account.
Using built-in support for logging in with email & password. This requires registration and account creation that is handled by Firebase. The user account information is stored outside you application.
Using a custom authentication to implement existing server-side authentication, single sign-on, legacy systems, or third-party OAuth based services (such as Yahoo).
Once authenticated, Firebase return a variable auth to your application that you can use for authorization and access control. This variable is null for unauthenticated users, but for authenticated users it is an object containing the user's unique (auth.uid) and potentially other data about the user.
If you want to persist additional user information such as name
and location, then you need to use auth.uid and store it in your
Firebase with additional profile data.
Internally, Firebase generates JSON Web Tokens (JWTs) and creates authenticated sessions by calling Firebase.loginWithCustomToken() with those tokens. Each user is assigned a uid (a unique ID), which is guaranteed to be distinct across all providers, and to never change for a specific authenticated user.
The user data for firebase authentication is stored in firebaseLocalStorageDb in IndexedDB. After login to website, if you delete firebaseLocalStorageDb, the login user data for firebase authentication is all deleted so you need to log in website again.
I've been working on a authorization service. It's a somewhat complex project, so I think it'll look good on a portfolio, but also it is a way to remove the reused code for every app I build. Just one central app where users are created, edited, allowed to set up security preferences and select what information to share. Users can have an account on my auth app, and share some info with other apps.
So not only do I have a create users, I've also given them the ability to create organizations and control certain requirements for auth on their apps, as well as create roles for users that have created an account on their app. This is where I'm having some issues. I'm using access and refresh tokens, rsa key pairs and jwts to authenticate each users on my site, but when creating an organization, I want to allow users to have multiple organizations if they want, and each organization should have it's own set of keys. While each individual org can set up their own authorization implementation after obtaining user info, they can only get that user info from the authorization server if they have the key associated with that app.
My problem is I don't know how I should implement this. I feel like I'll have to generate rsa keys, save one key to a database and have the organization save the other as a env variable. But should I save the public key to a db or the private? How do I even save a pem file to a db without changing the value? I'm just a bit lost on how this process can be accomplished with security in mind, but also while being dynamic. If I have to store private keys in my db then I'm very concerned about security as well. Can anyone break this down for me?
TLDR: trying to make google style universal login, need help storing and verifying rsa keys for organizations.
Context
I'm using Firebase phone authentication. and i have one mobile app for users and one web app for admin.
both users are stored in one collection.
Requirement
Now I want to validate that user is a admin when a user try to login in Web Application.
I keep data with users that "isAdmin" like this...
users:[
{
name:'John Doe',
phoneNumber:'+911234567890',
isAdmin:true
} ]
Now I want to validate every web authentication that user is an admin. otherwise i want deny the authentication,
Language: Javascript
Since the user's role is stored in a user document in a Firestore collection (named users if I correctly understand), when the user is signed-in (and therefore you have the user's uid and phone number) you should query the users Firestore collection to get his/her role (isAdmin true or false).
Then based on the role, you can either display the content of the Admin app or show an error and sign-out the user (you cannot "deny the authentication" but you can sign-out the user after he/she signs-in).
HOWEVER, the most important is to secure your database (and other Firebase backend services, if you use them) with some Security Rules based on the role. If your backend is secured, a non-authorized user who succeeds in opening or reverse-engineering your Admin frontend app can maybe see the GUI elements but cannot read and modify the corresponding data.
Since you store the role in a Firestore document, you need to use, in your Security Rules, the get() function, in order to get the contents of the user document. See the example in the doc.
Having said that, another classical approach to set up a role-based access-right strategy is to use Custom Claims, as explained by #Ashish in his answer.
One main advantage of using a Custom Claim is that the role (the claim) is contained by the ID token and therefore no additional lookup to a Firestore doc is needed to check for admin permissions.
You should note that you can only set Custom Claims from a privileged server environment by using the Firebase Admin SDK. This means via a server you own or via a Cloud Function (see this article, for example). You could also use the new dedicated "experimental" extension.
Setting the roles through a Firebase doc, as you do, is easier (just a document write or update), but you need to correctly secure the collection, in order to avoid a malicious user can modify a user doc.
Another advantage of Custom Claims is that they can be used in the Security Rules of all the services (Firestore, Cloud Storage, RTDB). With role declaration via a Firestore doc, you should note that you cannot get this role in a Cloud Storage or RTDB Security Rule (you cannot read Firestore from Security Rules of the other services).
I am trying to use a 6 digit code to log-in a user.
The code is available for 20 seconds and is unique to every user.
Briefly explained:
User is already logged in on a mobile app
User press the button "Get Unique Code"
Then, user enter the code on a WebPage on his PC
If the code is correct, show data for that user
What am I asking is if there is way to properly authenticate the user who introduces that code correctly given that I have the userID and all the informations about the user?
I can try and "fake log-in" (display all the information for that user when the code is correct) but there are some issues with this and I would like to avoid it.
I am using Firebase Authentication and Firebase Firestore. JavaScript is used for Web.
You can implement any authentication scheme you want by creating a custom provider for Firebase Authentication.
See Authenticate with Firebase in JavaScript Using a Custom Authentication System and Creating Custom Tokens with the Admin SDK.
In this flow you:
Sign in the users yourself.
Create a custom token for those users in a trusted environment, such as a server you control, or Cloud Functions.
Pass that custom token to Firebase Authentication, which can then use it to identify the user, and secure access to Firestore, Storage, and Realtime Database.
I am trying to remove a user programatically from my firebase. The method removeuser takes 2 arguments, email and password. Now email is not hard to find out since this is stored in the auth variable + I am adding it in my database when a user is created. However, how am I supposed to find out the password from the user?
When I create a user I do add the generated md5_hash information with this user in my database. However, I can not convert this value back to the real password.
I also obviously do not want to store the real password in the database since this is just asking for problems.
So I'm wondering, is there anything overly obvious I am missing here on how to remove a user programatically from the database, with his password? (Why do I actually even need his password to remove him?)
EDIT: To clarify, I am only allowing an admin to delete users, so he has a list of every user that has been created in my firebase. Having a user delete his own user account is still not so easy since (I presume) the firebase hashing algorithm is not public, so there's no way for me to check if he did input the correct password.
Firebase Simple Login is a service built on-top of Firebase Custom Login, and provides useful primitives for authenticating users via common means.
By design, Firebase Simple Login does not give you access to the users' passwords programmatically, as it only increases the risk that they are not handled or stored securely. Today, the only two methods that can be used to remove an email / password hash mapping is either via the client API using the email and password, or via the admin panel at https://<YOUR-FIREBASE>.firebaseio.com.
Keep in mind that when using email / password login, Firebase Simple Login simply creates a new mapping between an email address and a password hash, but does not store any information in your Firebase. Also note that there is no way to "blacklist" a user id, so if you remove the mapping, the user could re-create it.
If you want to ban / block users, a better approach would be to create a new list in Firebase of your "blacklisted" users, and then use security rules to ensure that that user is in the list (i.e. user is blocked if root.child('blocked-users').hasChild(auth.uid)).