1

In a Flutter + Firebase application I'm working on, user create an account (with Firebase Auth) and receive a verification email. However, this application is only for a select number of people, and therefore I have it implemented in such a way that new users are disabled by default and need to be enabled by in-app admins. It turns out that the verification link does not work if your account is disabled, so new users need to wait for admins to enable their account before they are able to verify. This is not ideal, and the desired workflow would be either one of these:

User creates account > account is automatically disabled > admin enables account > verification email is sent (preferable) User creates account > verification email is sent > account is disabled on verification > admin enables account > user gets notified that account is enabled (slightly less preferable because of this last step)

Option 1 requires some function to be notified once an account is verified so that it can be disabled, and I can't find any documentation on whether this is even possible. Option 2 requires taking over the verification emails send by Firebase Auth in some weird ways. My question is: is Option 1 a possibility? And if no, how to tackle option 2?

Wessel
  • 617
  • 4
  • 13

1 Answers1

1

To verify the email address for an account through the client-side SDK or REST API, a user needs to be signed into that account. If you disable an account in Firebase Authentication, the user can't sign in to that account to verify it.

Your options are to:

  1. Either handle the entire flow yourself, and then verify-and-enable the account using the Admin SDK. There is no step-by-step guide for this in the documentation.

  2. Or don't disable the account in Firebase Authentication, but instead only allow the user to use the app, and access the data, after they've verified their account.

The second option is by far the most common, as you essentially just separating the authentication part of the flow (the user proving their credentials) from the authorization part (the user gaining access to the app and its data).

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • Thank you for the clarification! We'll probably go for the first approach, as the problem with the second one is that even verified users should not be automatically granted access. I suppose it is not a very common approach because ususally you want as many users as possible and do not want to double-check every account. Good to know that it's possible still by writing our own flow! – Wessel May 06 '21 at 18:24
  • Good to hear this will work for you. I _do_ want to clarify something you still seem to confuse authentication (proving who you are) with authorization (being granted access to something). Only granting access to verified users is extremely common, but is usually done in the application code and security rules of the database. Even in the custom flow, you are going to do the same somewhere along the line: based on the credentials provided you're going to validate that they are who they claim to be, but don't have access to your app based on that. – Frank van Puffelen May 06 '21 at 19:38