Authentication on a secondary app (firebase 3)

[John Blair]

On my current angular / firebase 3 project I'm using the primary / secondary app feature to interact with 2 separate firebase apps from one website.

e.g

   // Intialize the "[DEFAULT]" App
   var mainApp = firebase.initializeApp({ ... });

  // Intialize a "Secondary" App
  var secondaryApp = firebase.initializeApp({ ... }, "Secondary");

This works great on the server, where you effectively have root access to the data, but I'm wondering how this can work on a client;

I'm using firebase authentication to log in via google / facebook etc, but that is done against an app (primary at the moment).

e.g

  mainApp.auth().signInWithPopup();

I'm not sure exactly how to authenticate my secondary app from a single login?
I can move the secondary lookups to the server, but I want to be able to use $firebaseArray for real time stuff, so would rather avoid the server if possible.

Cheers

John

[Jacob Wenger]

Hey John,

Each app has its own authentication state and you cannot transport that authentication state from one app to the other. So, in order to authenticate both apps, you'd have to do two separate logins. I'm interested to hear your use case here, if you wouldn't mind sharing it. Maybe I can give you some pointers on how to achieve what you want to achieve without having to use two separate apps.

Cheers,

Jacob

--
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 post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/aa6b41c9-0f5b-4bda-b635-c04b43ad1d34%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Blair]

Hi Jacob,

Thanks for replying. The use case is this: 

There is an existing website with firebase app behind it, which is used by staff for the company to maintain various bits of customer information (keeping the explanation very simple). 

I have been asked to create a second website that will be public facing, where the customers themselves will log in and perform certain functions.

At certain times we need information from both sources.

One option was to share the database between the two sites and segregate the data by function, but the owner had a strong preference to keep it separate for the time being at least.

On the face of it it seemed that was easily doable using the primary/secondary app feature, and indeed it works great server side, but asking users to login in twice doesn't really work.

As I mentioned I can get the secondary data server side but then we lose the real time goodness. 

The other it seems is to merge the databases so we only need to authenticate once.

Thanks

John

[Jacob Wenger]

It sounds like you'd be better off using a single database and then just using Security Rules to limit access to specific data. You can store an isAdmin flag under each user at /users/$uid and use a rule like root.child('users').child(auth.uid).child('isAdmin').val() === true to limit certain information to admin users. Should be much simpler than your current setup where you are juggling the config for two separate Firebase projects.

Hope that helps,

Jacob

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/8caca006-55b5-4d7a-a967-e825c08f26ba%40googlegroups.com.

[Joe White]

I would recommend that you keep your "company user data" SEPERATE from "public access data" -- we have all heard of hacking problems, haven't we (and data design seperation .. not just rules ... is now what we should think about).  I would consider creating an API to access a server that uses your "company user data" to return information to your "app runnign public acces data"

Jacob's suggest will work (technically) .. but in today's needed security conscious world, I would never recommend mixing important private and public data in a Firebase database just protected by rules.

[Mike Mcdonald]

Improperly implemented authentication and authorization systems are part of the reason why we live in a world with constant hacking--people (and companies) don't take the time to properly implement authN and Z because it's really hard to do correctly. Asking a developer to re-implement their own auth system (which they would have to do in the aggregated database world), or to perform two different forms of authentication (which they would have to do in the two database world) removes any benefits Firebase offers in this case, and makes the developer more prone to introducing vulnerabilities in their app.

I very much disagree that security rules aren't sufficient to keep your data secure, and I might even go so far as to say that the authentication and authorization model of the Firebase Realtime Database is the single biggest factor in it's success (likely tied with the realtime sync functionality). This system enables you to not have to do either of the painful steps listed above, and provides a very well tested (by billion dollar startups and Fortune 100's) and provably correct, patented security model that alleviates all this work.

We take thousands of line of code and transform them into tens of lines of config--compared to building, testing, verifying, and auditing your own system, this is the out of the box behavior of the Realtime Database. And because we know that even if we provide a config framework, misconfiguration can still occur, we provide a number of tools (like the security rules simulator), and our open source community has even created a tool that further extends the idea (Targaryen) to help you write secure rules the first time.

{

  "rules": {

    "public": {

      ".read": true

    },

    "private": {

      ".read": "auth.isAdmin() == true"

    }

  }

}

Is far easier than writing your own routes ;)

And if you still think rules are insecure, I welcome you to find an exploit in the rules system (for instance, read data in private without a properly scoped token) and email a repro to security at firebase dot com to let us know :)

Thanks,

--Mike

[Joe White]

Mike --

I appreciate your views, but being one victim of the US Office of Personal Management (OPM) breach, where my personal information, fingerprints, and other information was hacked .. because once authorization had been breached ALL information was available.  We need to separate information about people, customers and other entities so we don't use the "one big database with all info present" paradigm as the standard anymore.  We need to have information compartmentalised AND protected by "rules". 

Authorization (includeing two-factor authorization with a proper second factor) does need to be implemented propertly (ref: https://techcrunch.com/2016/07/25/nist-declares-the-age-of-sms-based-2-factor-authentication-over/).  For Firebase "auth" in particular, we need to complete the "email verification" element within the Auth system (currently missing but "planned" for Android, for example).

We are in this together .. I appreciate all your information below.  Let's together move implementatoins forward.

[Mike Mcdonald]

Joe,

I'm sorry your information was compromised--3/4 of my family also had data released, so I definitely feel and understand your frustration. That said, I think there were several major factors leading up to said breach: lapses in maintenance and testing of their security infrastructure, and potential state sponsored actors performing the hack. Since we can't prepare for the latter beyond performing the former, it's reasonable for us to claim that poorly implemented and maintained authentication systems were a major factor in this breach. The goal of not having to maintain your own system is that professionals can do this for you, and you can focus on your core competency (which is likely not building and maintaining authorization system--and if it is, email me directly, we're hiring :)

On the second point, about compartmentalizing data. In general, yes, it's possible that a developer induced bug in security rules (or an authorization system) could create a breach, in which separate databases (and also rules) could make a difference. That said, my point was that security rules, when implemented properly (which is easy to do given the tools we provide), are sufficiently powerful and secure for this use case. I would also argue that it's easier to create more vulnerabilities by adding complexity to the system.

On the Auth features: I definitely agree. FWIW, you can already use 2FA through social providers (Google Authenticator or a Yubikey with Google and Github), and email verification is on it's way.

Thanks,

--Mike