Firebase Auth provides a REST API to create/delete/edit auth users. As API Keys are not private, anybody can use the API.
The endpoint e.g. to create new users is publicly available and can't AFAIK not be disabled.
This is in my opinion a bad situation as e.g. an attacker could create via this endpoint lots of users which are no valid users for our system. An attacker could block valid email addresses of customers which are then not able to create their valid accounts.
If an attacker knows a userID he could even delete auth users.
We added user claims (which can only be set via the Admin API and not via the public API) to ensure only users created by us are allowed to access our systems but it would mean a lot of effort on our side to regularily delete users not created via our system.
Is it planned to protect FirebaseAuth also via AppCheck to allow only verified apps to access the auth api?
At this point, I would say it's unlikely as this type of abuse is considered a low risk in comparison to the APIs that app check is protecting.
The public-facing Firebase Auth APIs are rate-limited and the web APIs in particular must come from your permitted auth domains. However, one of the platform's key selling points is the ability to handle many concurrent users.
100 accounts/IP address/hour can be created
10 accounts/second can be deleted
Can handle 1000 requests/second, 10 million requests/day for public APIs across a project
The per-IP address limits are bypassed by using the Admin SDKs (subject to a 500 requests/second limit). You can also boost these limits temporarily from the Firebase Console if you are expecting a spike in demand (e.g. you offer a Black Friday sale).
Only the Firebase Auth API for creating users is "exposed", but limited as detailed above.
Editing, deleting, updating a user's details both metadata and the account itself are privileged actions - you must be appropriately authenticated to make changes. In the case of a user account connecting from a client device, you must have signed in within about 5 minutes to be able update/delete your own account. When using an Admin SDK, the requests are authenticated with a service account's credentials which authorizes it to make changes on behalf of users or the system.
If your system were to abused in such a fashion, reaching out to Firebase Support would be your point of call.
Related
I've read the docs about Firebase Auth Limits in https://firebase.google.com/docs/auth/limits. It states that there is a limit of 1000 requests/second per project. There is no example or any explanation about what those API Limits are. What kind of actions are counted in the API Limit? Does verifyIdToken() and createUser() in Admin SDK count as an API Request?
I am also aware that there is a duplicate question here but it hasn't been answered well.
I've asked Firebase Support about the API Limits and got the following response:
The API’s quota applies depending on the Firebase API you want to
use. In this case the API quota applies to the use of the Firebase Auth REST API. Using it, you can query the Firebase Auth backend
through a REST API. Also, it can be used for various operations such
as creating new users, signing in existing ones and editing or
deleting these users.
To create, and refresh a token the quota will apply, if you use the
REST API to do the operations. However, even if you don’t use the REST
API there are other internal quotas associated with the refreshing of
the token. In order to avoid refreshing the token so many times, set
forceRefresh to false to minimize unneeded token refreshes when a
valid token may still be cached.
I've also asked about the internal quota when refreshing the token using the official sdk and got this reponse:
Unfortunately, some quotas are internal, and confidential information.
For this reason, I am not able to share it with you. However, if you
receive quota errors you can contact us
The rate limit includes both the Client and Admin SDK:
The API limits encapsulates every request that comes from the API.
This includes various operations such as creating new users, signing
in existing ones, and editing or deleting users. The limits apply to
requests coming from both the Client and Admin SDK. This means that
Firebase allows you to have 1000 simultaneous requests/second (both
from Client and Admin SDK) in a project.
~ Firebase Support
I want to create a Udemy like video platform where a user can see all videos but can watch videos only that he has purchased.
I am making a rest call to get the videos from the storage bucket from an angular application, using Firebase authentication here. In my GET request to storage bucket I am passing the access token that I got from Firebase authn.
Does this access token can be used to determine scope of the user to access video in a bucket?
Assume if I have given read access for a video in a bucket for a specific user, using the access token can I get the video? But every time I tried it shows unauthorized. Is there any other way to verify users access to storage bucket object.
Google recommend to not use ACL because it's hard to manage and to have a global view on the authorization.
In most cases, Cloud Identity and Access Management (Cloud IAM) is the recommended method for controlling access to your resources.
Caution: Permissions can be granted either by ACLs or Cloud IAM policies. In general, permissions granted by Cloud IAM policies do not appear in ACLs, and permissions granted by ACLs do not appear in Cloud IAM policies. The only exception is for ACLs applied directly on a bucket and certain bucket-level Cloud IAM policies, as described in Cloud IAM relation to ACLs.
IMO, the best pattern is to have a database on your side with the file on GCS allowed per user. You can store these in Firestore: affordable, pay as you use, generous free tier. For downloading the video, you can generate a temporarily access to the user by generating a signedUrl.
As per mention Guillaume Cloud Storage use the ACL pattern in order to have a control to the access of the resources stored in their buckets.
Nevertheless, when you need to storage wide objects per user in this case a video, you can store these in Firestore: affordable, pay as you use, generous free tier. This is a very suitable option since Firestore can use as another resource
Is recommended for this scenario generate a signed URL
The firebase auth doc shows that you can only make Firebase Auth API calls up to 500 requests/second per service account & 1000 requests/second per project.
e.g. If I use Firebase Auth Admin SDK to invoke getUserByEmail or updateUser, do these operations count toward API limits?
How about verifying id tokens using verifyIdToken API? If my project verifies all requests coming in to the server from clients by verifying authIdToken, does that mean that my server's upper scaling threshold will be 1000 requests/second per project because the server's one of downstream services, Firebase Auth, can only accept up to 1000 requests/second to verify auth id tokens?
Firebase doc seems to be lacking details related to these API limits.
Yes, 1k/s includes all limits from the Admin API. I feel if the downstream can only handle 1k/s you can always implement a backoff or throttle algorithm to handle higher burst load at times. I assume these are mostly sufficient for user auth as user don't login frequently. For machine to machine, I suggest you use a different auth system.
I'm currently using Firebase for an online Android game in Kotlin (school project) to authenticate/register users. We're going to release our first version for testing, and I would like to set a limit of people that are able to sign up with Firebase (20 to be specific). Is this possible? Thank you in advance.
There is no way to limit the number of people that can sign in to Firebase Authentication. All authentication does is allowing you to say (and prove) that "I am Max", and there is no way to restrict in Firebase Authentication who can do that (beyond creating your own custom identity provider).
But you can limit what these users can do in the rest of your app. If you're for example using the Firebase Realtime Database or Cloud Firestore, you'd restrict the users who can access the database with their respective server-side security rules (Realtime Database, Cloud Firestore).
If you have your own backend servers, you'll want to pass the ID token from the user to that server, and verify the token there to allow who can access what resources.
If I share a user's Firebase device ID key (for a user who has my app installed) with other Firebase service providers, can they send messages from their account (using their authentication key) to a user who has my app installed?
Yes I do realize the process of sharing a user's Firebase device ID key could be problematic. The problem I am trying to solve is that I want multiple providers to be able to send messages to a user who has my app installed.
The Firebase Instance ID (also known as a registration token, or FCM token) identifies an installation of your app on a specific device.
Sending messages to such tokens in a project always requires an additional form "authentication.
The Firebase Cloud Messaging versioned REST API requires that the user has a service account. If you create a service account for each of your service providers, you grant them complete access to your Firebase project. So they can't only send FCM messages, they can also access every other Firebase product: e.g. delete your database, read all your users, etc.
The legacy REST API for Firebase Cloud Messaging instead uses a Server Key to authorize its callers. If you share your FCM server key with other service providers, they can only send FCM messages with that key. But they can send whatever messages they want to whatever user.
You might want to consider setting up your own API endpoint on Cloud Functions for Firebase. That way you can determine yourself how to secure that API, and what you allow your service providers to send to what users of your app.
Assuming that the Firebase Device ID Key you're referring to is the FCM Registration token, then having the value alone won't enable others to send a message to it without the corresponding Server Key it is associated with.
For your use-case of allowing multiple senders to a single app, you could refer to the official documentation on Receiving messages from multiple senders. I believe my answer here could also be helpful.