Is Firebase Authentication dead?

[Jacob]

I apologize for the inflammatory subject line, but I think this is an important matter that the Firebase and Google team should be transparent about.

What does the future of Firebase Authentication look like? Is it in maintenance mode? Is there any roadmap for future development?

I migrated my user base to the Firebase platform a few years ago, mainly based on their Authentication platform. It looked like it had a lot of promise. There was a lot of development going on with it at the time. Although it didn't have all features I wanted, the pace of development seemed to show a good trend line going in that direction. At the time, they said MFA was on the roadmap. I considered other AaaS options, but chose Firebase Auth based on where I thought it was going in the future.

Fast forward a few years, and it seems like there is no activity any more with Firebase Auth. I'm still waiting for TOTP and WebAuthN MFA. SMS is not a no-starter, and even Google has said that SMS is not secure MFA. There is no way to control the password strength policy, nor lock-out behavior when incorrect passwords are entered.

Now I need to make a decision: whether to stick with Firebase Auth, or to move on to a different AaaS platform. Will Firebase Auth pick up the feature development pace again, or is it on a long death spiral? I'd appreciate insight from Google what their plans are in a concrete way.

Thank you.

[João Paulo]

Doesn't Google Identity Provider solves your problem?

--
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/b0e07e31-534f-4b51-81a4-732fe5c57983n%40googlegroups.com.

--

JP Ventura
Computer Engineer - University of Campinas

https://br.linkedin.com/in/jpventura

Computer games don't affect kids.
I mean if Pac-Man affected us as kids, we'd all
be running around darkened rooms, munching magic
pills and listening to repetitive electronic music.

Kristian Wilson, Nintendo, Inc. 1989.
=============================================

[João Paulo]

Is it just me or has someone using Firebase Talk group to fish email accounts?

I got a link asking for passwords to https://alessandrors.atlassian.net/ from ji...@alessandrors.atlassian.net?

[Jacob]

No, we don't require our customers to have a Google account to sign up for our service.

[João Paulo]

No, I mean migrate from Firebase Auth to Google Identity Platform in a worst case scenario.

At least things will still be inside GCP.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/3eb1a903-129c-4ccc-8031-dbfd1c1dbbe6n%40googlegroups.com.

[Jacob]

Firebase Auth is Google Identity Platform. It's a just a branding. The technology and features are the same. There's been no development on Google Identity Platform in a long time. Their last release note was two years ago:

https://cloud.google.com/identity-platform/docs/release-notes

[Alex Devine]

Jacob, I agree with everything you've written, and I'm dismayed that Firebase Auth/Google Identity Platform hasn't really had any significant updates since they last released SMS-based 2-factor authentication nearly 2 years ago. These are pretty basic problems that makes Firebase Auth increasingly unsuitable for any security-conscious platform:

1. As you point out, SMS is the only current supported 2-factor option. The design of the API certainly made it seem like they intended to support other options (specifically TOTP and WebAuthN, and also email or phone call codes for those with only land lines - yes they still exist), but I've seen no update on this front for years.

2. There is no ability to remember devices when it comes to MFA - either a user is challenged with the second factor on every single log in, or not at all.

I certainly understand Google is reticent to give hard-and-fast deadlines, but to your point, if we could get some visibility at least into whether these "table stakes" features are being worked on would be extremely helpful to know if I should wait, or move to another auth provider.

Firebase Auth had such a great initial design, I'm just surprised it seems like it hasn't gotten any love for years.

[Alex Devine]

Responding to my own post because I devised a solution for customizing MFA behavior in Firebase, so thought I'd post it here in case it helps anyone else. Still, if anyone from the Firebase team sees this, would be so helpful to know the status of Firebase Auth.

Some notes about this solution:

1. It requires a backend for you to process the second factor challenge. Not a problem for us but if you're using Firebase with just the client-side Auth and things like Firestore, you'll need some other backend API, though this approach should also work even if you just use Firebase Functions for your backend.
2. It should also work with all of the Security Rules in Firebase, so you can protect access to things like Storage and the DB, ensuring the user has entered the second factor.
3. In addition to allowing you to customize the type of 2nd factor (SMS, phone call, email, TOTP, WebAuthn), it also allows you to do "remember device" functionality.
4. While it requires to do a substantial amount of processing yourself, it keeps the major benefits of Firebase Auth, e.g. never storing passwords in your infrastructure, and never even having passwords cross your network.

The basis of this approach is that it depends on having a "second_factor" custom claim on the JWT. That claim looks like this:

{

    "second_factor": {

        "type": "sms", // type can be whatever type of second factor you decide to support

        "device_id": "some-guid-here", // ID of the device where the user validated the 2nd factor

        "ts": 1234567 // timestamp of when the user validated the second factor

    }

}

Since this custom claim will exist on the JWT for users who have passed the second factor, you can then write your Firebase security rules to essentially consider a JWT withOUT this custom claim as not logged in. E.g. you can write a Firebase security rule to not allow access to a particular Storage bucket unless the user has this second_factor custom claim.

The workflow for authenticating a user, and presenting the 2nd factor challenge, is as follows:

1. On the client, log in the user as you would presently, e.g. const userCredentials = await firebase.auth().signInWithEmailAndPassword(email, password);
2. Get the ID token, e.g. const idToken = userCredentials.user.getIdToken();, and send it up to your API backend.
3. On your backend, the first thing you need to do is validate the token by using the Admin API, e.g. const decodedToken = auth.verifyIdToken(idToken);
4. If the verification succeeds, at this point you can double check that the decodedToken does NOT have a second_factor custom claim (it shouldn't if the user followed the flow above). At this point it is up to you to present whatever 2nd factor challenge you want to the user (i.e. the backend will return basically a "CHALLENGE_REQUIRED" response that the front end can then use to show a challenge). For example, if you have saved the user's phone number previously, you can send down a masked phone number and let the user choose if they want an SMS or voice call (E.g. "Send code to XXX-XXX-XX12 by _ SMS or _ Phone Call").
5. At this point you will have back and forth between the front end and backend to implement the challenge (e.g. send the phone call, and then present the user a screen where they can enter the 6 digit code, or just show the screen where they can enter a TOTP code). At all times you need to pass the idToken up to the server so that you can verify that "This user has logged in successfully, but hasn't yet finished the 2nd factor challenge". You are also responsible for things like rate limits.
6. If the user passes the challenge, then on your backend:
   1. First, you want to pull out any persistent custom claims that may already be on the decodedToken. For example, we save role information on our users in Firebase as custom claims. All custom claims you previously saved on the user will be accessible as top-level properties on the DecodedIdToken interface. We always scope our custom claims under a single top-level property so it's easy to pull them out, e.g. decodedToken.my_company_custom_claims.
   2. You then want to add the second_factor custom claim as shown above, e.g. const myCustomClaims = decodedToken.my_company_custom_claims; myCustomClaims.second_factor = { ... info as shown above ... }; If you want to set the device_id you should get that e.g. from a cookie set on the client.
   3. You then create a custom token on the backend and return this as a response to the front end. Importantly you'll be passing the additionalClaims parameter:
      const customToken = await auth.createCustomToken(decodedToken.uid, { my_company_custom_claims: myCustomClaims });
7. At this point when you return the custom token to the front end, the front end uses it to log in now:
   const userCredential = await firebase.auth().signInWithCustomToken(token);
8. The userCredential now has all the persisted custom claims of the user that first signed in, and importantly, it also has the second_factor claims.

At this point, whenever you validate a JWT, you should always check for the presence of the second_factor claims.

In addition, if you wanted to implement "remember device" functionality, so that the user needs to log in again but NOT be given a second factor challenge again from the same device, in step #4 above you can compare the device ID passed up in the request (again, just put this in a secure httpOnly cookie) to a list of remembered device IDs that you have stored for the user. If the device is a match and within the expiration date, then you can skip the workflow in step #5 and essentially just add your "second factor" claim like this in step #6: { "second_factor": { "type": "remembered_device", "device_id": "...", "ts": ... }}.

This is all obviously a non-trivial amount of work, but if you, like our team, are needing to do a cost/benefit analysis of migrating to another auth provider, the solution above at least gives you another option to compare.

[Alex Devine]

Sigh... Responding to my own post again because unfortunately after further investigation I found my approach above has a fatal flaw. This fatal flaw is correctable, but hopefully someone on the Firebase Auth team can see the great lengths we're going to in order to try to customize MFA.

The core problem with my previous approach is that while it's possible to write security rules in such a way that a user couldn't read/write to a FirestoreDB or Cloud Storage bucket unless they have successfully verified a custom 2nd factor, unfortunately there are client-side auth functions updateEmail, updatePassword and updateProfile that only require a valid authenticated user and have no way to restrict their access based on the presence (or absence) of custom claims on the JWT. Thus, it would be possible for a bad guy, for example, to just authenticate with a username and password, and then call updateEmail or updatePassword to change a user's email or password withOUT requiring the 2nd factor.

Thus, the solution is to ensure a client-side user can never get a valid JWT unless they have validated the second factor. That can be accomplished using the beforeSignIn blocking cloud function that is available as part of Google Identity Platform:

1. The beforeSignIn function is only called when the user's previous credentials (i.e. username and password) are correct as determined by Firebase. Importantly, beforeSignIn is not called when doing custom authentication.
2. Thus, the trick is to ALWAYS fail in beforeSignIn by throwing an error message like the following:
   
   const uid = user.uid;
   const hmac = ... use a library, e.g. Node crypto, to create a HMAC of the uid signed with a secret key...
   throw new gcipCloudFunctions.https.HttpsError('failed-precondition', JSON.stringify({ uid, hmac }));
   
   
3. On the client then the original call to signInWithEmailAndPassword(email, password); will fail , and the client will need to catch and look for the `failed-precondition` error and error message. Note this is quite similar to how the stock 2nd factor works now, where you need to look for the auth/multi-factor-auth-required error), e.g.:
   
   try {

1. 
       const userCredentials = await firebase.auth().signInWithEmailAndPassword(email, password);
   

1. } catch (err) {
       if (err.message.includes('BLOCKING_FUNCTION_ERROR_RESPONSE') && ... need to parse out the details of the uid and HMAC from the message, see here.) {
           ... then user needs a second factor verification - pass the uid and HMAC up to your server ...
       } else {
           ... handle other errors like username and password invalid ...
       }
   }
2. All the steps 3-8 in my previous post are now the same, except when the user is in the "verified email and password but not yet 2nd factor state" you'll be passing up the uid and HMAC and verifying that instead of calling auth.verifyIdToken(idToken) on the server. Be careful how you verify the HMAC on the server, e.g. in Node you need to call crypto.timingSafeEqual().

The nice part about this approach is that it guarantees that a client user will never have a valid JWT except for the one created with await firebase.auth().signInWithCustomToken(token);. That means you wouldn't even have to modify any security rules, because you can be assured that if a user has a JWT on the client that they passed 2FA.

And again, while there is work involved here, it still allows you to always store the user's creds (username and password) and other info in Firebase and never get access to the password directly (a good thing), and take advantage of Firebase Security Rules, but allows full control over the method of 2nd factor.

[Kato Richardson]

A couple ideas:  a) store a value in your database in an admin-only read/write path containing the last 2FA verification timestamp or b) add a custom claim to the Auth token from the verification service. Then you can check this against your security rules to enforce access based on 2FA. That should get rid of most of the pesky edge cases.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/bd7d1e96-1196-4125-94a5-2bb85edbb2f1n%40googlegroups.com.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[Alex Devine]

Kato, regarding your approach, that is what a I originally planned to do (add a custom claim to the Auth token and then check security rules against that to enforce 2FA) but as far as I can tell that approach is not secure. The reason being that the accessible client-side auth functions updateEmail, updatePassword and updateProfile do not make use of security rules - all they require is a recently-authenticated JWT - and thus if you used that approach users could change their email, password, or profile without needing to validate the second factor; obviously, that is a catastrophic flaw.

[Kato Richardson]

While it is true that I can sign in without enforcing the 2FA, that wouldn't allow me to set a custom claim or database value, so it would still effectively prevent access. I realize it's possible to change a password if I can guess the original, but it still doesn't gain me anything other than inconveniencing the real user as they will have to reach out to a support team and request a password reset. I'm of course not stating this is ideal, but it's pretty far from catastrophic.

If that's just not acceptable, then I'd recommend signing up for Google Cloud Identity to get a real version of 2FA or simply waiting until we get it pulled into Firebase Authentication; I have high hopes that will happen in a sane future.

☼, Kato

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/642d3eb6-861b-4ead-a512-992942534a9an%40googlegroups.com.

[Alex Devine]

Thanks for your response. I agree with what you've written, "that wouldn't allow me to set a custom claim or database value, so it would still effectively prevent access", but I pretty strongly disagree that allowing a non-2FA'ed user to change email, password or profile information is just an inconvenience, and I think any security review would flag it as a non-starter. That said, your point is totally valid.

Regarding Google Cloud Identity (and I think you may have meant Identity Platform, not 100% sure) to get a real version of 2FA, we are on Identity Platform and use SMS 2FA now, but what this whole thread is about is getting better forms of 2FA given how much even Google itself has said SMS 2FA is insecure. Indeed, I find the design of the SMS 2FA in the APIs now to be very well defined, and it seems obvious that it was designed with the intent to extend to other forms of 2FA (e.g. base interfaces of MultiFactorInfo, MultiFactorResolver, etc. with the Phone... concrete implementations now), so just bummed it's been so long without guidance from Google/Firebase on the roadmap. 

[Kato Richardson]

Hi Alex,

I did mean Identity Platform, thanks for that (internal names don't always align perfectly). Thanks for clarifying that you are more focused on the nuances between SMS vs. other MFA solutions; that helps quite a bit as I assumed there were more options for Identity Platform and I obviously have some more reading to do. This is all wonderful feedback and I've already shared it out with some of the product managers responsible for deciding where these belong on the roadmap. Please keep sharing.

☼, Kato

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/13611926-ce93-4631-bb56-cc2298a6db92n%40googlegroups.com.

[Jacob]

Hi Kato,

Thanks for acknowledging the need for more MFA options. Your customers and your customers' customers want it really bad! :-). Look forward to hearing good news soon.