I'm making an app that has Firebase as its database. The app shouldn't need the user to create an account to use it, but I want the user to be able to read/write their data onto the database (so maybe they have to create an account?).
Do I have to make the users create an account in order to use Firebase?
My problem is that my security rules are read/write are allowed for everyone (which I know is wrong, but how do I change them and not need users to create an account?) Maybe that's the issue.
It is best to ask them to create an account
Although:
it can be a non-real email address and
there is anonymous auth also available
It sounds like you need the app to remember that user's particular data, so that when they return to the app, it is still their data (and not someone else's) that is being accessed.
To achieve that, we need each person's data to be stored in a different place in Firebase. Traditionally, this is by having them log in to some kind of system, most conveniently Firebase itself, and then the data stored in a branch of the database defined by their user Id.
Without logging in, you could simply ask the user for an identifier, such as "Bob" or "Carol", and then store their data under their identifier. The Firebase database would therefore have the following structure.
users/Bob/highScore: 3000
users/Bob/level: 7
users/Carol/highScore: 5050
users/Carol/level: 9
However this is not secure because there is nothing stopping Carol coming to the app and saying she is "Bob". Any such client-side activity you carry out to attempt to identify the user is not really authentication (in the opinion of Firebase) because all client-side activities can be faked relatively easily.
Firebase Authentication
The standard solution is to use Firebase to authenticate each user (see the Firebase authentication docs for this), and give your app a user Id (such as "8769dsg6f8g7698769876sdgs9") which is unique and known (by Firebase) to be correct.
Firebase security rules
You can then lock down the database using Firebase Security Rules so that only user 8769dsg6f8g7698769876sdgs9 can write to any of the users/8769dsg6f8g7698769876sdgs9/.... part of the database.
If you don't use Firebase to authenticate the user, Firebase will treat the user as unauthenticated and you will have no way to restrict each user to their own section of the database. Either you leave it wide open (to hackers etc!) or users will not be able to access their own personal data on it.
They can use a FAKE email address and password
If your concern is that they won't want to give out their real email address, you can ask them to make up any email address, e.g. mickeyMouse49857430679304#hotmail.com, and set a password. There is no obligation on your app to contact them on that email address or verify that the email address is correct.
Whenever they come back to the app, or access it on another device, they need to remember the fake email address and password.
Of course, if they lose their password, there is no way to reset it.
Anonymous Authentication, but at risk of losing access
The legendary Frank von Puffelen of Firebase, himself, has added a remark about Anonymous Authentication, in the comments below. From what I understand, this avoids them having to make up a fake email address.
I think the weakness of this is that if they lose their local web storage (e.g. if they manually wipe it, or move to another device), there is no way for them to re-access the same account, unless they have planned ahead by adding an email/pw to the anonymous account.
The only real way to have security per-user data storage is to use Firebase Auth to sign in the user, and write security rules to protect the database so that each user can only access their own data. There are no secure alternatives to this for Realtime Database.
Related
I'm quite new to firebase and I am looking for best practices using it, maybe I will be able to get some advices here.
What I want to do:
User login using firebase.
Problem:
I save user info in firebase but use SQL server as database where I need that user information as userId
Question: How should I approach that?
Register user on firebase and when I get response with userId and token, save it to my sql database too?
what's my current approach:
At this stage we're thinking of creating new users via admin panel (and then these users can sign in)
Would it be good approach to add user to sql database, send email to finish registration (create pasword) and then add this user to firebase, and with response send request to my backend where I update user that he's verified, add userId and token?
It's very common to store additional information about Firebase Authentication users in your own database. Whether it's good in your use-case is subjective, but it's definitely common.
Assuming that you have a server interacting with SQL server on the user's behalf, be sure to pass the ID token from the client to the server, decode it there, and then use the UID (and other claims) from that token in your database interactions. Don't allow the user to just pass their UID, as that'd be a security risk.
For more on this scenario, see the Firebase documentation on verifying a user through their ID token.
Your approach with an admin panel is a common first approach, but not something I'd recommend. Since you'll need to allow the user's to sign in with email/password, there is nothing keeping them from calling the createUserWithEmailAndPassword API themselves on your project. So I'd recommend leaving the creation completely to the clients, and save yourself from having to consider that an abuse scenario.
If you want to control what users an access the data, store a list of email addresses (since you seem to associate that with uniquely identifying a user already) in the database, and check the email address in the ID token is in the list (and is marked as verified in the token).
I'm currently developing a web app using firebase authentication to make sure only authorized users can access the backend (e.g. firestore).
However, I don't really care about differentiating users but just want a single password based login/authentication. Meaning users come to the site, enter the password they know and then they get access to the protected data (e.g. from firestore). No need to create a own account.
However, I don't think firebase auth supports something like that.
What would likely work is just using .htaccess to protect the page and then provide users with anonymous accounts once they can access the app/page.
However, the browser popup caused by this is not nice enough for my purpose, I would prefer a nicely styled password form in the actual browser window.
What I could try is creating one account and sharing the password for that with all users (and set the email in the background). However, I'm not sure whether this works fine (e.g. multiple users being logged in at the same time on the same account).
Am I missing a simple option to implement such a single password based login shared between users?
Or is it e.g. possible to send a password to cloud functions, check it there and return an access token for an anonymous account from there to the user?
You can just create a single Firebase Auth email/password account and share the credentials with everyone. As long as you trust that each user will not share them with anyone else, and you trust that they will not maliciously overwrite each others' data, it should be fine.
According to firebase doc, it seems that client side SDK allows email address as well as user profile information to be updated directly.
https://firebase.google.com/docs/auth/android/manage-users#update_a_users_profile
If I build an android app without any UI workflow for users to change email address, I am confident that majority, 99.99%+ of the regular users, will use the app as intended.
However, if certain users investigate/reverse-engineers into the app, learns that it uses the firebase, wouldn't it be possible for them to debug and invoke any one of the Firebase Auth client SDK methods provided? (e.g. Wouldn't it be possible for hacker to change email address [not supposed to be allowed in my app after initial registration] & change photo url to point to something inappropriate images?
With Firestore database, I could use security rules to prevent read/writes, but I wasn't sure how I could do something similar in Firebase authentication.
Yes, it's possible for users to get a hold of the token that would be used to call the backend APIs exposed by Firebase Authentication that would normally be used by the SDK. There is no equivalent to database security rules.
The fact of the matter is that users normally should be able to change their email address, as they might actually need to change email provider at some point. If your app doesn't allow this for some reason, and you have a hard requirement to only use the email address provided by the authentication provider(s) you allow, you should consider writing that value to a database at the time the user account is created. Then, use security rules to prevent the user from changing it there. From that point on, you would only ever trust the value initially written to the database, and never use the email address from the auth provider.
You would probably want to handle writing to the database from a Cloud Functions auth onCreate trigger, so that you control all the logic.
I am now facing the same issue, and I think I will just not worry about the 0.01%. This is mostly because if they change their own email with Firebase Authentication via reverse-engineering and my web server is unaware of their new email, this would not have any impact on the other genuine users except maybe not being able to find them (email is only used in searches for now).
I am working on Firebase application ( Firebase version 4.1.3 )
My health care related application is made for dependent group of people such as children and seniors. However, most of my users are independent group of people age around 18-55. Most of my users use my application for their seniors/children. They need to create account for each of their family seniors/children member. Therefore, my users have to log in and out many times and they have to keep track of their family members' account. My first thought was I should make an account switching feature so that my user can switch their account back and forth between their family members to update information on my application.
After searches on Google, I found way to force switching account on Firebase authentication with Google provider, but those are not what I'm looking for.
My questions are:
Is it possible to store the multiple firebase auth objects (logged in object) in client side?
If it is possible, for how long will the token inside the firebase auth object last for?
If it doesn't last forever, is it possible to refresh update the token so that it can be use without authenticating with the social/phone login again?
The functionality you are asking for is not available out of the box. You have to build it on your own. I do think Firebase provides the pieces to allow you to build it (via Auth and Database).
Is it possible to store the multiple firebase auth objects (logged in object) in client side: You can have multiple Firebase app instances and each one have an auth instance with a current user. You would need to ask each user to authenticate though (you can't authenticate once and sign-in into all of the account). However, you can build your own user group login mechanism, where logging in with one "master" account can allow you to login with multiple accounts using custom Auth.
If it is possible, for how long will the token inside the firebase auth object last for. Firebase sessions are supposed to be indefinite. If a token expires (typically after one hour), it can be refreshed automatically if you are using real time database.
I do not think Firebase has that token capability. But what you could do is simply put the email address of the people in the device by Shared Preferences( for Android). When the user wants to log in with that user bring the email address just ask him to enter the password and then go through the log in process. If you do not want to use SharedPreferences you could simply store the users(also as you said family members) in Firebase Database and link them with the controller user so to speak. Whenever user wants the switch, go and bring the email addres of other family members from Firebase Database and ask in the client for the password and do the login by Firebase Authentication.Hope that helps!
If a user logs into my Firebase store with Google authentication, the client gets access to all sorts of useful user-specific information, like the user's name and email. I might want to put this information in the store, and the client can certainly send it along in a write request. But as far as I know, there's no way to validate (on the server side) that this information is correct. There is nothing stopping someone from using a second client to send fictitious metadata.
(For instance, take a look at the skeletal auth variable which is accessible from security rules. It doesn't contain the information I need for validation.)
How do people deal with this kind of situation?
Only limited information about the user is available in the auth variable in security rules.
To access more information, you'll have to store that information in the database when the user is created or signs in. Most developers add a /users node to their database for this reason.
You can then look the extra information up in your security rules with something like root.child('users').child(auth.uid)...
The process is covered in the Firebase documentation section on Storing User Data.