I intend to use Firebase Queue to push tasks for registering a user using his/her mobile number like Whatsapp for a mobile application. I am using a third party service to verify a user's mobile number. The verification process is a two step process
Send the user's mobile number to the third party service which returns back a request_id and sends a code to the user's mobile via SMS
Send the request_id and code entered by the user and verify it
This is like the first thing that I would do when the user open the mobile app for the first time after installing. Since the user is not even registered yet, there is no auth data for the user.
I want to ask what kind of security rules can I add to the firebase queues so that no outsider can add/remove tasks to the firebase queues.
I can also expose APIs on the server directly which the mobile app can use to perform the above verification but I am thinking that if there is a way to add some security rules to the firebase queues for such a scenario case also, then I would rather have the mobile app talk to only firebase.
I have created the following sample code
1.Queue worker
2.Client
Currently, anyone who knows my app location can add a task to the queue. Since, the user has not been authenticated yet, I cannot add any auth specific security rules to firebase. I was thinking of shipping the mobile app with an application secret and have something like this for the security rule for the firebase queue
{
"rules": {
"queue": {
"tasks": {
".write": "newData.appSecret === <appSecret>"
}
}
Here <appSecret> is what is shipped with the mobile app and each new task also contains the appSecret in it. Now, only clients who know the appSecret can add tasks to the firebase queue.
Related
Start Notes :
When a mobile application starts with Firebase enabled, the first thing that happens is Firebase creates a Token ID for the device on that app.
This requires the device to connect to the Firebase server, and register the device with all the required data about the device.
Unfortunately this cannot happen if the device has blocked access to the Firebase server.
Searches :
As I know, there is a Firebase Admin API on the server side, that can be used to create functions and probably one of them is to create a custom Token ID and register the device using that ID.
However, searching Firebase Docs, only creating a Custom Auth ID appeared
Create Custom Tokens
But this Token ID is not for the device, it is for the user on the device (i.e, Firebase Authentication API).
Goal :
What I want to do, is handle the entire Token ID process from the server side, so that even a Firebase blocked device can be registered on Firebase.
Question :
What is the method of creating a Firebase Token ID on the server that also registers the device as a user with its data (Device Name, OS, etc)?
Is there such a process? Or does Firebase exclusively register the device from the client side?
Side Notes :
I believe it is possible, as some applications that obviously use Firebase Messaging are available for use even when Firebase's access is blocked.
Examples : Discord, Telegram.
The token ID is managed by the client device. The backend and admin SDK are not involved in this process. It's the responsibility of the client app to send this token to you backend, if you need to target the app for use with Cloud Messaging. If the app is temporarily unable to reach your backend, you will have to retry sending the token until it's able to reach the backend.
I haven't seen any examples of this, but I want to purely interact with Firebase through the backend, and not the frontend with Javascript.
I have auth tokens being minted on my Go backend when a new user is added and then these users are written into a mongo database.
What I want is to be able to get a messaging token for my users, and then add it to their user document in mongo, that'll be used to send messages through the backend.
The reasoning is that we don't want to have to communicate with Firebase on our frontend.
Is this even possible?
If you want to send a message directly to a device with Firebase Cloud Messaging, you will definitely need some information from the client. There is no avoiding following the setup instructions on the client. In particular, you will have to handle the registration token on the client and send it to your backend so it can send the messages.
The Firebase Authentication token will not be useful to you at all for sending messages. FCM doesn't send messages to users - it sends messages to devices (or topics). You will have to figure out for yourself which devices belong to which users.
I implement user signup logic in my nodejs backend server. It uses firebase for username and password signup. Below is the code used in nodejs:
var firebaseClient = require('firebase');
firebaseClient.initializeApp(config)
firebaseClient.auth(). createUserWithEmailAndPassword(req.body.email, req.body.password).catch(function(error){
console.log(error);
})
the problem for this approach is that firebase has a usage limit which is 100 accounts/IP address/hour. All users who signup in my application will go to my nodejs server first. That means firebase will think there is only one user. It will meet the usage limit very easily. I know I can put the signup process in the frontend but I don't like doing this. Because my signup logic needs to save something in my local database as well. I wand them to be in one place. Does anyone know how to handle the usage limit in my case?
The Firebase-Auth AdminSDK should not be rate limited so you can use it on your NodeJS server without any problems to handle as many user authentications as you require.
Make sure you don't use the client-side javascript SDK, which should not be used on the backend, but instead for frontend consumers like IoT, WebApps, Consumer Desktop Apps..
More info on the difference here: https://firebase.google.com/docs/admin/setup
As part of our solution, we want to deploy an FCM "app server" at each of our customer sites. Each customer site has their own users with their own devices using our app. However, we want to make sure that if one of the customer sites is compromised, an attacker could not abuse the FCM "app server" (e.g. by sending notifications to all devices at all customer sites).
Instead of sharing credentials between all customer sites, we are thinking of generating a unique server key for each customer site. That way if one customer site is compromised, we can disable that server key and stop any more FCM notifications from being sent.
Question: Can we be sure that an attacker cannot send global notifications to all devices?
Assuming an attacker has a server key and access to one customer site "app-server", can they get a list of all the registered devices?
Is there a default notification "topic" that is sent to all devices? (e.g. /topic/all or /topic/global). If so, can we disable that default topic?
Instead of sharing credentials between all customer sites, we are thinking of generating a unique server key for each customer site. That way if one customer site is compromised, we can disable that server key and stop any more FCM notifications from being sent.
If by "we are thinking of generating a unique server key for each customer site" you mean that you'll simply create a Firebase Project for each customer site, then I think this is the correct approach.
Can we be sure that an attacker cannot send global notifications to all devices?
An app can receive messages from a different Sender by implementing the getToken(authorizedEntity, scope) which will generate a different token for each Sender. In order to negate this action, you could simply call deleteToken(authorizedEntity, scope) (my reference).
This would invalidate the token for that corresponding sender (which is what they probably have and should be the only one on their App Server), which would automatically disable them for receiving messages to your App.
So as long as you're able to remove them as a valid sender from your app, then it's all good.
Assuming an attacker has a server key and access to one customer site "app-server", can they get a list of all the registered devices?
This depends on how the App Server is implemented. If the customer's App server is only used for sending messages, but the tokens are stored elsewhere, then probably no. There is no API to retrieve registration tokens on the server side for an App based on the Server Key (see #1 here).
Is there a default notification "topic" that sends to all devices? (e.g. /topic/all or /topic/global). If so, can we disable that default topic?
There isn't. There is the option to send a Notification to a specific app via the Firebase Notifications Console, but if the app doesn't authorize the Sender ID corresponding to that project, it won't receive any messages from it. I've tested this behavior out before posting, so I'm positive that this is how it works.
There is no way to restrict a server key to only allow certain topics/devices/etc.
I would consider using Cloud Functions for Firebase to solve this a different way. You could build an HTTPS function that took per-site authorization tokens (by any means you deem fit) and then that function calls through to Firebase Cloud Messaging to actually send the push notifications.
This way, you have complete control over what kinds of push notifications can be sent by the "client" sites, and you don't have to worry about cascading security problems in the event a client site gets compromised.
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.