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.
Related
I know that firestore cannot set the rate limit separately. (prevent same firestore repeat requests)
Is it possible if I use "App Check"?
It seems there is no question about this.. so I ask
Firebase App Check does not enforce any rate limiting. It just provides attestation of app or device authenticity. If you enforce App Check, any unverified requests (without App Check token or with an invalid token) will be rejected.
Checkout this video to learn more about App Check.
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.
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'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.
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.