Authentication when accessing Firestore and Cloud Functions from multiple projects

[Arne Wolframm]

Hi!

According to the FAQs, only a very small number of apps may be connected to a single Firebase project, seemingly due to a (arbitrary?) limit of 30 OAuth2 IDs per Firebase project.

I am developing a point of sale app for restaurants. The app has the special feature that it gives each restaurant client the option of having their "own" white label consumer mobile app that is connected to a single Firestore instance that stores all customer, consumer, sales and menu data for all restaurants.

Now, until I realized that I cannot have a large number of mobile apps connected to a Firebase project, using Firebase seemed to be a great solution. However, realizing the project app limit is tiny, I can only think of one other way to structure my system on Firebase using multiple projects:

ONE BASE PROJECT

This single Firebase project hosts my Firestore instance, my cloud functions and ideally the table of all authenticated users.

MANY WHITE LABEL CONSUMER APP PROJECTS

This type of project is connected to a single restaurant's white label consumer app. There could be 100s of these white label projects if my business idea is successful, all using data from the BASE PROJECT.

Each white label app project is connected to one Android and one iOS app written in Flutter. As far I understand https://firebase.google.com/docs/projects/multiprojects, it is easy to access the BASE PROJECT Firestore and Cloud Functions from each white label app by instantiating a "secondary" Firebase application object.

However, what is unclear (to me) from the Firebase docs is how user authentication is handled and security rules are handled with regards to the secondary Firebase application object.

1. Can I use my base project's sign in methods to authenticate users of the WHITE LABEL apps? Can I have a single user base for all my white label apps and the base project by handling user sign-in through the secondary Firebase application object (connected to the BASE PROJECT) or does this require adding each white label app to the base project and thereby running into the tiny 30 OAuth2 ID limit again?
2. If I must handle user auth in each white label project separately, will each user still receive a globally unique user ID, i.e. one that is unique across all my Firebase projects? Also, will requests to the BASE PROJECT Firestore and Cloud Functions from WHITE LABEL app user still be populated with a correct request.auth.uid, so that I can manage access rules, as if the users who make calls to BASE PROJECT's Cloud Functions and Firestore from WHITE LABEL apps were actually BASE PROJECT users?

My questions follow after reading the docs for AWS AppSync and Cognito. AWS seems to provide far clearer docs and also their user handling seems more advanced than Firebase's. It appears in AWS I can connect 1000s of mobile apps to a single AppSync'ed DynamoDB database using a single user pool for all apps. This would obviously be the best solution for me, but unfortunately I already invested a lot of work in Firebase, so first I will try to make my app work on Firebase. However, please help me answering the above questions so I don't need to waste time trying to do things on Firebase that cannot be done.

Best,

Arne

[Jeremy Sistrunk]

Is your billing set to Blaze?

Sent from my iPhone

On May 28, 2020, at 8:03 AM, Arne Wolframm <arne.w...@gmail.com> wrote:



--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/1d4ba1d3-ef01-4af7-b142-ebab6de537c2%40googlegroups.com.

[Sam Stern]

Hi Arne,

Our FAQ has some guidance on your original problem:
https://firebase.google.com/support/faq

> A project is a container for apps across iOS, Android and web. While there is no restriction on number of apps within a project, adding an app can create one or more underlying OAuth 2.0 client IDs. There is a limit of around 30 client IDs that can be created within a single project.
>
> You should ensure that all apps within a project are platform variants of the same application from an end user perspective. For example, if you develop a white label application, each independently labelled app should have its own Firebase project.

Your apps do *not* need OAuth 2.0 Client IDs to connect to Firestore.  They're only needed for Google Sign In and a few other things.  So if you're using email/password auth for your apps you can simply delete the auto-generated OAuth 2.0 Client IDs and then have more than 30 apps per project.

- Sam

--

[Arne Wolframm]

Yes

You received this message because you are subscribed to a topic in the Google Groups "Firebase Google Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebase-talk/7CwiXth42wQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firebase-tal...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/4D3B9C63-1646-4DBD-B10F-949754D09534%40gmail.com.

[Arne Wolframm]

Hi Sam,

Thank you for clarifying that! I guess I could live with Email/Password auth. However, would it still be possible to offer other OAuth2 login providers, for example Facebook?

Your solution would be the easiest to implement. I did in the meantime find this blog post on the Firebase blog, which describes connecting apps in one project to other projects while even retaining a single user ID. That post never made it to the Firebase docs, though, so is it still current?

Arne

To unsubscribe from this group and stop receiving emails from it, send an email to fireba...@googlegroups.com.

[Sam Stern]

Hi Arne,

Yes you could still use Facebook Auth and all of the other auth methods besides Google auth and SMS auth.  There are a few other features that require an OAuth Client ID, such as Dynamic Links.  But the majority don't need it.

As for the blog post: yes the concepts in that blog post are still 100% valid.  It's from 2016 so obviously some of the code snippets will have changed and the advice about firebase.com projects is irrelevant (those are long gone).

- Sam

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/90ead3b5-796c-43b4-99e4-bc502b5efd48%40googlegroups.com.