I have a public web app that has no app-logical need for users/authentication, but that does rely on Firebase back-end features, such as cloud functions and Firestore.

Given that, is it still best practice to create anonymous users? I'm having a hard time seeing the benefit. If I created anonymous users, I could restrict their invocations, but that seems pretty easy to get around, and I'd rather not restrict the average user while still leaving the door open for someone nefarious.

In apps that do require users, sign-up, payments, etc, I usually start functions with something like if (context.auth && context.auth.user.isSubscribed) { // run app logic } and it feels a bit naked to be without that -- but I'd be delighted to skip that if it's not a security gaffe.

My bottom-line concern is about sudden, massive costs if I have a truly public cloud function, but maybe that's unfounded.

CodePudding user response：

Use anonymous authentication to persistently associate data with the user, without having any identifiable knowledge about that user. So a typical example is to allow the user to put something in the shopping cart before they sign in. Using anonymous authentication allows you to associate the cart with the user and secure access to it, without requiring the user to enter credentials.

If you have no need to associate data with the user, there typically is not reason to sign them in anonymously.

Just signing the user in anonymously is (contrary to semi-popular belief) not a security measure. As you already said: anyone can call the API to sign in, so just requiring that some is signed in doesn't deter much abuse.

In your example of context.auth.user.isSubscribed however, the user also needs to have an isSubscribed claim. This sort of claim can typically only be set by somebody who has access to your projects administrative credentials, so that sort of check is a useful security measure. And in fact, it's what I said at the start, a piece of data that you persistently want to associate with the user.