2

There is a warning on the Firebase best practices documentation against using Firebase with multi-tenant applications: https://firebase.google.com/docs/projects/learn-more#multi-tenancy

This is what I am most concerned about: "Multi-tenancy can lead to serious configuration and data privacy concerns problems, including unintended issues with analytics aggregation, shared authentication, overly-complex database structures, and difficulties with security rules."

There is also plenty of official Google documentation supporting the use of Firebase for multi-tenancy, for instance: https://cloud.google.com/identity-platform/docs/multi-tenancy-authentication .

Do you know why they would have these conflicting recommendations and examples? Does use of Google Identity Platform fix the core security deficits mentioned in the warning?

I am re-posting this question, with additional clarification in the title, and a few edits/removals from the body, to specify that I am only looking for why this widely used product has this particular warning in its official documentation. I have removed most subjective content. I have no opinion on this that is relevant to the question - I am only looking to understand the warning. It seemed there was one good answer before the previous question was closed, so I will link that here for reference: Why is Google Firebase not recommended by Google in their own documentation for multi-tenant applications?

David
  • 300
  • 1
  • 14
  • 1
    This question is not an on-topic Stackoverflow question: a) Your question is not about programming or software development; b) your question does not present a problem that can be answered within the guidelines of Stackoverflow; c) your question asks for opinions. The probable answer is that Google chose to not support multi-tenancy for Firebase. – John Hanley Jun 02 '21 at 04:42
  • @JohnHanley Fair enough. I already marked the one answer as accepted, as it provided good contextual understand based upon an understanding of a good example use case. Also, Google did choose to support it, as I referenced in the second link. That is why I was puzzled. Yet I couldn't find an explanation for this discrepancy in their documentation or in the many online code snippets or tutorials explaining multi-tenancy with Google Identity Platform (which works with Firebase auth), so I thought the community might have an answer based upon their experience. – David Jun 02 '21 at 07:15
  • 1
    I would agree the question is off topic; it's not a bad question but it's not a good question for SO. That being said, the bottom line is that Firebase is not a multi-tenant platform where each tenants data and users are separated. It's not whether google supports it or not, it's the inherent nature of how Firebase works. Imagine retail store inventory control system. The stores and users are all separate (tenants), independent and never share data but the way Firebase is built, all of the data from all of the stores would be 'together'; that's a security/privacy issue, hence the warning. – Jay Jun 02 '21 at 19:08
  • @Jay Thanks for the explanation. I found this resource: https://stackoverflow.com/help/on-topic I meant it from a technical standpoint, but I suppose this point could apply to my question: "Questions asking for customer support with third-party services (such as App Stores) are off-topic for Stack Overflow. Instead, please direct your questions to the relevant company/organisation's technical support team." Unfortunately GCP has difficult to reach technical support, but that's not SO's problem, haha. – David Jun 17 '21 at 07:36

1 Answers1

5

That does make sense if you manage 2 separate applications which have no relation with each other. Let's say you have an app that manages a school's information and other one is a restaurant management app. Now in this case I don't see any event that the school app might need access to restaurant data.

If you use the same project, then all the firebase services (auth, database, analytics, etc) will be shared among them. It'll be hard for you to separate analytics for each of the app. As the database is shared, you'll have to explicitly separate data of both apps by separating the path in db. (/apps/school for school, /apps/restaurant for restaurant).

That being said, any user registered on the school app can login on restaurant app without creating a new account there as you are sharing the same project among them.

Now if your client pays you a the Firebase costs every month, you cannot distinguish between how much should the school client pay. Now even if both the apps are your, the complexity will increase significantly if you go on using it.

https://firebase.google.com/docs/projects/learn-more#multi-tenancy <-- this explains how "Firebase Projects" works and https://cloud.google.com/identity-platform/docs/multi-tenancy-authentication explains about "Google Identity Kit" multi-tenant auth. So that's not a Firebase-only thing.

Dharmaraj
  • 47,845
  • 8
  • 52
  • 84
  • Thanks, this provides good contextual understanding. I think I see why they'd recommend it outside the context of a Firebase hosted app - e.g. when using Google Identity Platform. The multi-tenancy example could be run from Google App Engine, and so wouldn't necessarily be subject to the same issues. Also, your example about the school / restaurant apps I think gets at the root of what they were warning against in Firebase. Which is using the same Firebase app for multiple apps. However, having multiple organizations within one app is a bit different (and more common, in my experience). – David Jun 02 '21 at 07:11
  • 4
    @David if the app is something that manages multiple schools (or organizations as you mentioned), then it'd make sense to have it as a single projects as when a user logs in, you'll be showing information relevant to them only. Also the db structure will be uniform throughout as everything is a school and not restaurant. That's like Discord where users create servers. All the servers are same and managed in a single db kind of. – Dharmaraj Jun 02 '21 at 07:29