Firebase authentication - many users logged with the same credentials

Question

In my job, we needed to implement authentication because of security and we wanted the DB not to be completely open. We have implemented anonymous authentication because the app is not based on a user profile. It works well, but it is creating too many users (every time the app is uninstalled or the cache is cleared a new user is created). Although there isn't any limit for anonymous users, it is not good to have so many UIDs in the project.

Now I was thinking of creating one user in the console (email/password authentication), and all devices authenticate using such email and password.

Would there be a problem with that? Would Firebase limit the number of sessions with the same user?

My app has about 20 000 active users. Is it a problem with 20 000 sessions at the same time and also with so many requests to Firebase products with the same user? It's important to be completely sure that a limit problem will not occur before I make that migration from anonymous to email/password (unique user).

Answer 1

Now I was thinking of creating one user in the console (email/password authentication), and all devices authenticate using such email and password.

While this approach might work, this is not how you should handle authentication. Why? Simply because when you're using a single account, a single UID will be generated. That means that 20k users will share the same UID, which is bad because you cannot write proper security rules. You might think, that you can find another way to differentiate one user from another, like an IP, a device ID, and so on, but unfortunately all these IDs might change. So you'll end up having trouble.

My app has about 20 000 active users. Is it a problem with 20 000 sessions at the same time and also with so many requests to Firebase products with the same user?

It's not about a limitation as it's about managing users and security. Besides that, in terms of app design, each user should have their own account. As also @Tim mentioned in his comment, the best option that you have is use continue using Firebase Anonymous Authentication and enable automatic clean-up. In this way, you'll have a database containing only active users, since unused accounts will be deleted after 30 days. That being said, since each user has their own account, you can link that anonymous account with email and password, and you'll have distinct accounts for your users, and the most important part is that you'll be able to secure your app properly.

Edit:

Given that my app and DB are not based on a user profile, such rules like auth.uid==$user.uid or $user.role=='admin' are useless.

Understanding that security isn't a concern, then you can ignore that and use a single account.

I just want to know and be sure that the approach of using a single user for all my devices will work and won't occur limit problems.

In most cases, folks are trying to limit access to the app on multiple devices, but if your application requires a single account, then you can go ahead with that. Regarding limitations, there are no limitations when it comes to how many users can access a single account, as there are no limitations when it comes to how many users can authenticate into your app.

Edit2:

Yes, the following limitation:

Operations per service account: 500 requests/second

Refers to the maximum number of operations that can be performed in a single second. But, that's a large number in my opinion, given the fact that a single user needs to authenticate only once since the auth state persists across application restarts. So the need for a user to sign in or out it's not so often. Besides that, I don't see any reason why a user should sign out.

So even if you have 20k users, it's hard to believe that more than 500 will try to perform an operation in exact same second. Even if that happens, you can catch the error and display a message to the user in which you can ask to try again in 5 seconds, for example.

Once all those 20k users are authenticated, I cannot see how you can reach that limit. I think that even Facebook doesn't have more than 500 new users that sign in to the application in a single second. Because if so, in a single minute they would have 30k new visitors, and in an hour would have 1.8 million new users. I let you do the math for a day. So it's quite impossible.

Answer 2

Authentication is not attestation.

If you are using Anonymous Authentication and still serving data and only restricting the access of that data to whether a UID is present in the request, then anyone can still generate an anonymous user and access your database through a series of rest calls since generating an anonymous user has no barrier to it.

It sounds like what you really want to do is implement AppCheck. AppCheck will ensure that your users are only accessing your application and database through approved applications and not accessing it through REST calls or other service calls. What you could do is enable AppCheck on your project and then enable enforcement when all your users have migrated to the latest edition of your app. Your DB is still able to be accessed, but only if it has a valid AppCheck token which can only be provided through an attestation provider like SafetyNet or reCaptcha.

Answer 3

Firebase allows 50k monthly active users at the free tier but gets expensive very quickly after that. If you have Firebase Authentication with Identity Platform setup, you can enable automatic clean-up so stale accounts are removed if not used.

You could deploy a blocking function with Cloud Functions that triggers a beforeCreate event. First, you could log IP addresses when a new user is created, then could run a check to see if that IP is already in use with beforeCreate. Obviously, there are many reasons why that could fail but it would at least reduce the number of duplicates.

The best thing would be to force a real sign-in method after a user is anonymous for some period of time. You can easily link an existing anonymous account to a social provider or other method to reduce friction for the UX.