Two-factor authentication (2FA), sometimes referred to as two-step verification or dual-factor authentication , is a security process in which users provide two different authentication factors to verify themselves.
This plugin facilitates Two-Factor Authentication (2FA) implementation for your application users. It is a JavaScript One Time Password (OTP) library designed for OTP generation and verification. The plugin is specifically compatible with the following authenticator apps:
Google Authenticator Authy Authenticator Microsoft Authenticator
Key features of the plugin include:
Enable 2FA for Your App Users:
Generates a QR code for adding the userâs secret key to authenticator apps such as Google Authenticator, Authy, and MFA Authenticator.
OTP Token Verification (30 seconds token expiration):
Provides functionality to verify OTP tokens within a 30-second timeframe.
Server Token Validation:
Validates the OTP with the server token and returns the status of the 2FA verification process.
We are planned to provide Free of this plugin service to the first 10 customers of their bubble applications.
Avail of this plugin free service from the Demo link and enter your name, email and bubble app name. once your submitted your details, you can install this plugin to your bubble editor after 1 or 2 hours.
Instructions to install this plugin
You can go to your bubble editor â plugins.
Click âAdd Pluginsâ, Popup will visible and search for this plugin.
Thatâs a nice offer for the community. Thanks, @mani2726.
However, I canât get your instructions to work. The âAvail your Free access to this Pluginâ button doesnât appear. In poking around the editor, it looks like maybe thereâs an unintended redirect away from the â2fa-enableâ page or maybe something is off in the conditional expressions that govern that buttonâs visibility.
Thanks, @mani2726. I performed some initial testing of the plugin. The core functions seem to work great. I tried the 3 authenticator apps you list, plus Last Pass Authenticator and Symantec VIP Access; every one worked. I look forward to fully implementing it and piloting with my users.
Hereâs some feedback regarding suggested improvements:
The reference documentation is sparse. It would be helpful, for example, to have each of the actionâs propertiesâReturn Data (for both enable and verify), Secret Key, and Error Detailsâexplained on the plugin page.
Authenticator apps normally display for each accountâs both the app name and the user login id. Itâs clear where to specify the app name in the pluginâs action, and that indeed propagated to the authenticator apps. However, the authenticator apps only showed âundefinedâ for the user login id. If thereâs something Iâm implementing wrong, I donât know what that is.
âInvalidâ is misspelled as âInvaliedâ in an error message.
@mani2726 , is there any update regarding propagating the login id to the authenticator app?
Also, how does the plugin handle a user who has lost access to their authenticator app? Many apps that support 2FA address this need by providing to the user, at the time of initial configuration, a batch of authentication codes to archive for future reference. Does the plugin provide any such mechanism?
You can ability to pass your âUser IDâ to this plugin.
Fixed error message to Invalid.
If user lost their authentication app then, you can reset their reset their 2fa secret key. or show the generated QR code (Very 1st time you need to save this generated QR to your database for reuse) to rescan and setup into app.
User can copy the Secret key and manually adding this key to the Authendicator app then, it works.
In retesting the plugin just now, it looks like the Bubble Userâs email does propagate to the authenticator app. Thanks for making that work.
I still see âInvalidâ misspelled as âInvaliedâ in the error message generated when an invalid token is submitted.
I donât follow your instruction for how a user who does not have access to their authenticator app can still authenticate. It sounds like youâre explaining how a user can re-connect their account in my app to their authenticator app, which makes sense. Nonetheless, they need to first authenticate so that my app knows who they are, and I donât see how to do that. Does the plugin provide some type of self-serve functionality analogous to Bubbleâs own action to Generate one-time backup codes?
It sounds like youâre saying that you updated the plugin. However, I donât see a new plugin version: Itâs up to the Bubble user. You typically need to refresh the Bubble editor to get the latest plugin version for update.
In retesting the plugin just now, it looks like the Bubble Userâs email does propagate to the authenticator app. Thanks for making that work. Thanks
I still see âInvalidâ misspelled as âInvaliedâ in the error message generated when an invalid token is submitted. This has already been updated in the latest version. Please verify itâŚ
Nonetheless, they need to first authenticate so that my app knows who they are, and I donât see how to do that. Does the plugin provide some type of self-serve functionality analogous to Bubbleâs own action to Generate one-time backup codes? This plugin does not provide or support backup code.
Note: My suggestion is to use a secret key or any keyword as a backup code for manually validating the user via backend workflow / action.
I had indeed previously refreshed, so Iâm not sure why the new version wasnât initially appearing. Regardless, the new plugin version does appear now. Thanks for confirming.
The new User ID property reliably propagates to the authenticator app. If left empty, the email of the User appears instead.
âInvalidâ is spelled correctly.
My suggestion is to use a secret key or any keyword as a backup code for manually validating the user via backend workflow / action.
Iâll work through that idea and hope that my customers who require MFA consider that approach to be compliant. Itâs unfortunate your plugin apparently cannot support backup codes, which seem to be the standard approach used by many apps.
I completed implementation. Hereâs a summary of the verification (not initial configuration) flow in case it helps others.
When user enters email and password and selects button to sign in, app sends those credentials to an API workflow to check whether they are valid and, if so, to also check whether the userâs account has 2fa enabled.
Alternatively, the app could sign in the user in the front end in order to then directly check whether 2fa is required for the userâs account. However, that would then require populating a verified yes/no field for the user and also implementing on all app pages that should be available only to authenticated users an initial redirect that runs when the current user is logged in and has 2fa enabled for their user account but their verified field is ânoâ.
The data in the API response drives the next actions.
a. If the credentials were not valid, then a login action runs in order to trigger the browser notification that the user couldnât be signed in.
b. If the credentials were valid and the userâs account does not have 2fa enabled, then a login action runs to sign in the user.
c. If the credentials were valid and the userâs account does have 2fa enabled, then the app prompts the user to enter a code, which the app sends to another API workflow for verification. If the API response confirms verification, then a login action signs in the user; if the API response does not confirm verification, then the app prompts the user to correct the code.
* This action indeed must be in the backend since you donât want to expose the userâs 2fa secret key to the client browser, which would enable anyone to then replicate the userâs configuration in an authenticator app. Also, use privacy rules to exclude the userâs secret key field from everyoneâeven the user themself.
To address the need for backup codes, I implemented functionality to generate and verify them directly. Theyâre not valid for the pluginâs verify action, but it was straightforward to provide users with the alternative of either entering a code from an authenticator app, which can be verified via the pluginâs action, or from their saved backup codes, which can be verified via a separately defined action.
