I've been using Firebase as a way to synchronize data between a Rails application and a mobile web-kit based application. I've recently been attempting to use the email/password authentication method in lieu of custom auth tokens.
Everything works as expected, but my concern is with user creation and authentication.
Currently, I'm able to create a user, both on Rails (using a self-modified version of the firebase-ruby gem) and through the mobile app, using the firebase node module.
So from the stance of a malicious user, is it correct to assume that I can create a Simple Login user with the JS library (for anyone's firebase instance), and then authenticate with that user, and attempt to read any data that they have stored?
Of course one shouldn't leave their entire Firebase data structure unprotected. So this only works in a situation where one has only set up the default security rules.
Either way, is there any way to prevent anyone from creating users, except for myself (or some other authorized person) without resorting back to custom authentication? I understand the difference between authentication (the server knows who you are) and authorization (the server is letting you in).
Any feedback is appreciated.
In my conversation with Frank, it appears that there is no way to prevent malicious users from creating any number of accounts on a Firebase instance through email/password Simple Login. This doesn't allow them authorization to any data per se, but could be annoying for the SysAdmin/DevOp who was maintaining the Firebase instance.
Related
I am currently developing an iOS appplication using xcode and Swift. My application works well with firebase including the function of email verification. Due to the nature of my application, I want users to be able to sign up, verify their email and then await further verification on the side of my client using firebase.
In an ideal world, firebase would have a setting that supports user being automatically disabled on signup, and you would just tick a box and the user would be enabled in the authencation page of the console.
Seeming as I am looking for my client to be able to do this, I need a way that is simple to them, so they can enable and disable accounts. There is a property in the firebase authencation page but no way to default it.
So.. My idea was to create a cloud function in firebase that automatically disables users on signup, and once my client has verified who they are they will enable them. Any ideas on what this function would look like? Disabled is a nice and easy boolean value so.
I am new to firebase, so wondering if anyone had came across this kind of issue? The link below shows the function on user creation.
https://firebase.google.com/docs/functions/auth-events#trigger_a_function_on_user_creation
You can add an Admin SDK function in the user creation event you have. See this for an example: https://firebase.google.com/docs/auth/admin/manage-users#update_a_user
The easiest way to automatically disable new user accounts is through Cloud Functions. See for an example the answer to this question about How to prevent new user registration on Firebase?.
But note that the user will already be signed in by the time the Cloud Function runs, so they'll have access until their current/initial ID token expired (up to an hour).
The proper solution is to check whether the user is verified before enabling any backend functionality. For Cloud Firestore, Cloud Storage, and Firebase Realtime Database, you can do this in their server-side security rules. See for some examples of this:
(Firebase) Firestore security rules - allow if email verified without custom tokens?
Security rule to only allow write for users with verified emails
How do I lock down Firebase Database to any user from a specific (email) domain?
My goal is to prevent users of multiple login in. I do not want this to be client-side, with like the onDisconnect and onConnect values, but with a server check. I came across this answer:
How to prevent simultaneous logins of the same user with Firebase?
Which tells me to create a custom auth system. When I am following the docs (https://firebase.google.com/docs/auth/ios/custom-auth) I need to "Copy this file to your authentication server" (3c). How would I do this? I am just using Firebase and my little iOS app. I would like to manage everything on these 2 things, no server in between, is this possible? Or can this file only be uploaded through another server?
If above things are not possible, how can I server check if the user really signed in? I am using Cloud Functions, but I did not came across a trigger for a user signing in. Please no answers with onDisconnect/onConnect, I want it server side. A user may NOT login if he is already logged in. Thanks :)
Implementing custom authentication requires that you have a secure place to mint the custom token that identifies each of your users. You cannot do this securely with only client-side code, because that would mean everyone could claim to be whoever they want.
While you can use Cloud Functions for Firebase to implement a secure back-end without spinning up your own server, I highly recommend against doing that just for the purpose of preventing a user to sign in from multiple locations.
It's important when talking about security to split these two steps:
Authentication - a user proving to be who they are
Authorization - the authenticated user being able to use your app
There very seldom is a reason to keep a user from proving who they are. Your concern seems to fall onto keeping them from using the app from multiple locations. To do that, it's probably easier to track for each user where they are using the app from already using Firebase Database's presence system.
Also see:
How to handle multiple connections of the same user on Firebase?
Android - How to detect same user from multiple devices?
How to prevent same user logging in from different devices ? My app is paid , so I dont want credentials to be shared
I have an existing rails application where the users can register, login and do a few activities. Now I want this to be done through an api so that this it could be used from some kind of external app like for an ios or android application.
I have doubts on how to approach this. I have before created versioned apis and also secured them with the technique of uuids for each user. But here, I already have validations for the user model which validates his email, password and stuffs. I dont think that would be a rightful approach when it comes to the api, specially for a mobile app user to be entering a password to register is not the common practise I think. If some one could suggest an idea where the api could be integrated with the existing application logic and let me know how to bypass these validations, it would be of great help.
I have two Rails apps, and I would like to accept user login credentials from one app (say App A) in another (say App B). For the app that's accepting login credentials (App B), I think the best option is to use OAuth. But for the app whose user credentials are being used (App A), how do I allow the user's login information to be used by another site? Do I use OAuth as well, or something like Doorkeeper? As you can tell, I'm very new to user authentication, so any advice would be helpful!
One possible way to solve the problem is to create a doorkeeper-based standalone app that would contain all of a user's credentials. Then your client apps would actually connect with this "auth app" (using Oauth.) Then when the client is authenticated on the Auth App, they get returned to the Client app. Of course, from a UI perspective, you make this seamless, so your login page would actually be on this Auth app, but it would look seamless to the user. This way, you can add as many apps as you want and the credentials would all be in one place. To answer your specific question, you would use Oauth2 on your Client apps and Doorkeeper on your Auth App.
You'll need to tweak the doorkeeper configurations to make this process "clean" to the user. For example for internal apps, you can safely use the skip_authorization method in doorkeeper. Learn more about that here
This doorkeeper/oauth system has the added benefit of decoupling your authentication logic from your main application, which is fundamental to good Service Oriented Design. There are certainly other ways to approach this problem, but given the context of your question, yes, Doorkeeper and Oauth2 would solve your problem.
I have a web app that needs to provide lightweight user access to a mobile client, via an server side API.
These users need to be authenticated, but do not need to ever login to the web app itself.
Instead of creating a traditional User model, with authentication/authorization, I am thinking of instead creating api keys that get emailed to the relevant user email, so they can just use that to access the mobile app.
Has anyone used this approach before?
I know you shouldn't send access credentials via email. But I can't think of another way without going for the full blown User model approach, which is overkill here, in my opinion.
Thoughts on a postcard please.