I want to let my customers send push notifications to their users. I am using Firebase Admin SDK for that, which requires the "service-account.json" file. For security reasons this file should not be shared with others. How could I make this feature available to my customers, without sharing any "secret" information?
If you want to allow your users to send push notifications, you'll have to make a custom API endpoint that you can call from the application they use. It's quite common to use Cloud Functions or Cloud Run for this, but any trusted environment you may already have can work too.
By running the code that sends the message in an environment only you can access, allows you to securely use the Admin SDK that has full administrative access to your Firebase project.
Then when this code gets a request from a user running your app, it needs to check whether this user is authorized to send this message to the user(s) they are trying to send this to. Exactly how to check authorization depends on your app, but some things to consider:
Is any user allowed to send a message to any other user, or is there some mechanism where they opt-in to receiving messages from each other?
Can any message be sent, or is there some mechanism that validates the messages, for example by detecting whether any foul language is used?
These are just some examples of the types of checks you might want to do, and the actual list completely depends on your app and its use-cases.
Related
I am using firebase admin sdk on the server to generate sign in links and send them out via custom SMTP api.
I just glanced at https://firebase.google.com/docs/auth/limits and I am well within these, but I believe there is nothing stopping a malicious third party from creating/requesting sign-in links via front end code. Is there a possibility to disable this functionality so it is only available to admin acc?
Additionally, I'd like some emails (i.e. multi factor enrolment) to not be possible, but again, given that someone can obtain some of my firebase front end details, they technically can send these?
You can restrict the API key from accessing an API (e.g. Identity Toolkit) but not disable a single method of the API for client.Sign up and delete user can be (that requires upgrading to Identity Platform) .
Firebase generates an API key when you add a web app. You can either update that or create a new key from API Credentials console.
You can then restrict what the API key in Firebase web config has access to:
However, Firebase Auth Client SDK will not work as Identity Toolkit is not selected. You'll have to proxy the requests through your backend and use a different key that can be used from your server's IP only.
Firebase Admin SDK will still be functional as usual so you can use that to perform other operations like updating/deleting users. You'll just have to write APIs on your backend for what could have been done using client SDK directly (or use Admin SDK when possible).
It might be a lot to update and I would not recommend unless you are facing rate limiting issues where Firebase Support should be able to help.
Disclaimer: I am new to mobile app development and have little to no knowledge on authentication systems
Normally, when my mobile app makes https calls to my backend server, I know that I cannot trust that these calls to my server came from my app, as anyone can make https requests to my backend server. Even if I give the app a secret key, it is still possible for a hacker to obtain the key and include it in https requests. Therefore, I will not allow https requests to accomplish whatever it wants on the server; rather, I will limit the request to doing only what a user can normally do with their own data – delete their OWN posts, edit their OWN profile, and so on.
Does Firebase work the same way? I saw this StackOverflow thread regarding OAuth consumer secrets, and how they can be compromised and used to imitate a mobile app.
Is this also the case for Firebase?
Can a malicious user theoretically obtain whatever keys/secrets Firebase gave to my mobile app, and use that to emulate requests from my app to Firebase? For example, could they create new users and cause de-syncing issues with my own backend database?
If so, how can I prevent it?
Thanks.
Does Firebase work the same way?
Firebase works in whatever way you program it. Normally you do not put private keys in software that you distribute to end users. The recommended approach is documented very well - use Firebase Auth ID tokens to indicate who is making the call, and use code on your backend to figure out if they should be able to do the work they are requesting. This is what happens with direct database access from your app, but you have to write security rules to protect data according to your requirements.
If you are passing tokens yourself to your own backend, it is up to you to revoke any refresh tokens that you find to be compromised. You cannot fully stop hackers from compromising a system that stores user tokens on devices that you don't control. All you can do is make it hard for them to do so.
Can a malicious user theoretically obtain whatever keys/secrets Firebase gave to my mobile app
Yes, that's why you don't put secrets in code that you distribute to end users. The Firebase config that you're asked to add to your app is not considered private.
See also:
Is it safe to expose Firebase apiKey to the public?
I'm developing an android app with firebase as a backend and I heard a word named Admin SDK. I had searched for it and found it is used to manage data.
But I have a doubt that firebase provides a console webpage (console.firebase.google.com) to manage data, but why there is a separate Admin SDK?
Can someOne please explain...
The firebase admin SDK provides a simple and easy way to modify firebase settings and data using API calls.
For example, you might ask: why should you even have a regular SDK to store data? After all, you can store and save data directly from the web interface. It is, however, simply not secure or practical to have users update their own data each time using the console.
Similarly, the admin SDK is just like the regular SDK but with administrator permissions. For example, it allows you to bypass the rules set up using your firestore rules. The Firebase admin SDK is meant to be used on your backend - so you know it is running trusted software. You know that it will act the way you expect it to, unlike code running client-side that can't be trusted.
For example, let's say that you want to be able to delete a user's post if certain conditions are met. The user will make the request to your server, and it will check if the conditions are met, and then delete the post using its admin privilages. Sure you could technically automate this using firestorm rules, but those can be quite cumbersome and might not work in more complicated examples.
You can also even use it to integrate with other applications like connecting your app to a moderation tool or a curse detector that can't or shouldn't run on the client's device.
Is your question is why does Admin SDK exists?
There are several administrative tasks such as deleting users, listing collections and many more which the client cannot and should not be able to do.
Firebase Admin SDK has admin access to your Firebase project's resources.
It does not obey any security rules and can read/write any of your database, storage bucket..
That is why you must use Admin SDK in a server (or cloud function only). Although I feel Firebase Admin SDK is more useful if you use your own servers and authentication method. If you are using a custom server then:
It can be used to generate custom token so you can authenticate users using your own method (maybe legacy auth system) but still use Firebase Authentication to handle the auth tokens thereafter.
If you use your own database (and not any from Firebase), the Admin SDK can verify the ID Token sent by client and get identity of that user. Thereafter it's could be a simple if-else statement for you to decide if the user has access to the request resource or not.
Firebase allows users to change their email client side with
firebase.auth().currentUser.updateEmail("example#example.com")
However, I would like to disable this feature entirely - obviously, I offer no way to access it on my app by default, but if an attacker managed to trick the user into install a Chrome extension or otherwise was able to access client credentials, I would always want it to fail if possible.
Is there anywhere on the Firebase auth console where I can change this functionality or a Cloud function that would stop users from changing their email?
At this moment in time, I do not see anything in the console or otherwise to disable this functionality. As it stands, there are only two Cloud Functions available for Firebase Auth events - user creation and deletion, so that would probably not be applicable to this use case either. The only thing I can think of is to just use the Admin SDK and your own API / backend to facilitate custom authentication for this scenario.
I am working on a project that might use Firebase only for messaging. The goal is for the following to happen:
App registers with Firebase on startup
App sends Firebase token to our server
Our server sends Firebase messages to all clients via the token from step 2
Note there is no step where the user will log into anything or enter any credentials. I am a little confused if this is possible in a production app, as most Firebase documentation talks extensively about different ways to authenticate, either via username/password, OAuth, etc.
The server will be sending different messages to different clients, but that logic will be handled by the server and not by different types of registration to Firebase. I know Firebase supports groups, but to make a long story short it probably won't be leveraged.
Can all this be done on Firebase? Is GCM a better match for these requirements? I feel like we would be throwing away 95% of Firebase and just trying to force it to simplify the messaging part.
Firebase Authentication does not at all affect the way that Firebase Cloud Messaging works. FCM only cares about the token for the app on the device as a means to target the app for messages. It doesn't care at all if the end user is authenticated by any means. If you want to associate a token to a user somehow, using Firebase Authentication or some other system, that's up to you.
FCM is an evolution of GCM. They are powered by essentially the same components. Using GCM doesn't give you any additional constraints or flexibility than FCM, except for the path to integration in your app.