We’re excited to announce the release of version 1.37 of FusionAuth. It shipped in August, 2022. The 1.37 release includes bug fixes, multi-factor authentication (MFA) policies for applications, an API to mark a user’s email address as verified, and the ability to limit webhooks to certain tenants.
This release contains many new features, enhancements, and bug fixes. As always, please see the release notes for a full breakdown of the changes between 1.36 and 1.37.
There are a few such changes worth highlighting, but wow, there’s a lot of stuff in this release. Please, please, check out the release notes.
Configure MFA requirements for an application
Previous to this release, you enabled MFA on a tenant by tenant basis. When a user had MFA enabled, they completed the MFA process for every application they logged in to.
In conversations with customers, we discovered they were using FusionAuth as a CIAM system for more than one type of application, and that our MFA implementation was lacking.
Some applications were low risk and consumer facing. For these, our customers wanted to ensure new account creation and onboarding was as easy as possible. One example of this is a freemium gaming application.
Other applications were higher risk, with a corresponding greater need for identity assurance. For example, an internal application where compliance requirements dictated MFA or a customer application allowing valuable transactions such as a financial transfer.
If you enable MFA for all users, the first application’s onboarding and growth suffers. If MFA is disabled, the second kind of application is riskier and in some cases in violation of governance policies.
The solution is to allow MFA to be enabled or disabled on a per application basis.
To do so with this version of FusionAuth, log in to the FusionAuth administrative user interface, navigate to the “Applications” tab and edit your application. Proceed to the “Multi-Factor” tab and choose from the “On login policy” dropdown.
You have four choices. You can:
- Disable application specific MFA configuration. In this case, the application will have the same behavior as it did in previous versions of FusionAuth as described above.
- Enable the application specific MFA configuration and set the “Trust policy” to “Any”. Then, if the user has completed an MFA challenge for any FusionAuth managed application, they will not be challenged again for this application until the timespan configured for “Two-Factor trust” has expired.
- Enable the application specific MFA configuration and set the “Trust policy” to “This application”. In this case, if the user has completed an MFA challenge for this application, they will not be challenged until the duration configured for “Two-Factor trust” has expired. However, if they have completed the MFA challenge for another application, they’ll be prompted to complete MFA when they try to log in to this one.
- Enable the application specific MFA configuration and set the “Trust policy” to “None”. The user must complete an MFA challenge for every login to this application.
Note that this doesn’t enforce MFA if a user doesn’t have one or more MFA methods enabled. There’s a recommended workaround for that documented in the MFA guide. This functionality requires a valid FusionAuth license. Please see the pricing page for more information.
Webhooks, applications and tenants
Previous to this release, a small but non-zero number of webhooks could be associated with an application. This was not recommended and caused confusion for our users. In this release, all webhooks are associated with a tenant; you won’t be able to configure application specific webhooks any more.
However, you will be able to associate a webhook with zero or more tenants. This can be useful when segmenting environments using tenants. You typically don’t want your production webhooks to receive events from the staging tenant and vice versa.
If you currently have a webhook associated with an application, it will be transparently migrated. Each application specific webhook will be associated with the tenant containing that application.
The code receiving the webhook should be modified to handle events from other applications in the same tenant. If you are only interested in events for a certain application, filter in the code receiving the webhook. For example, if you are interested in the “User Registration Create” event for an internal admin application, filter and discard events sent by other applications.
You can review your existing webhook configuration by using the administrative user interface or by running this script:
INSTANCE_HOSTNAME=... # your instance's hostname
API_KEY=... # an API key with at least `GET` permission on the /api/webhook endpoint
curl -H "Authorization: $API_KEY" https://$INSTANCE_HOSTNAME/api/webhook|jq '.webhooks|.[]|.id,.global,.applicationIds '
This will show all webhooks. Any with a value of false for the global field is an application specific webhook. For these webhooks, the application Ids will be displayed as well. These are the webhooks you’ll need to modify.
Verify an email address without sending an email
Email address verification is critical for CIAM systems to ensure accounts are created by legitimate users. Additionally, self service workflows such as password resets require a valid email address. FusionAuth supports email verification. Prior to this release, there were a number of ways to verify a user’s email address, but they all sent emails to the user’s inbox.
However, you may want to verify an email address without actually sending an email. Example use cases include when you’ve already verified the email address through another system, because you provisioned the email address yourself out of band, or because there’s a registration workflow outside of FusionAuth which has confirmed deliverability.
You can now use an API call to mark a user’s email as verified:
INSTANCE_HOSTNAME=... # your instance's hostname
API_KEY=... # an API key with at least `POST` permission on the /api/user/verify-email endpoint
curl -XPOST -H 'Content-type: application/json' -H "Authorization: $API_KEY" https://$INSTANCE_HOSTNAME/api/user/verify-email -d \
'{ "userId": "429797ba-37d7-4bbe-8748-58fb812448ff" }'
You can also specify, when creating a user using the admin UI, whether or not to verify their email at the time of creation.
Goodbye Tomcat, hello Netty
Another change in this release opens up some exciting new possibilities. With 1.37, the infrastructure underlying FusionAuth is changed: out with Tomcat and in with Netty.
Tomcat has been very good to FusionAuth over the years. But Tomcat has some architectural assumptions. Moving to a more customizable foundation layer like Netty allows better cookie handling and flexibility around configuration reloading.
While this is a functionally equivalent lower level change and shouldn’t have any impacts on you and your users, we look forward to the future features this will enable.
There are, however, some configuration changes that have been made obsolete or changed. See the release notes for more details.
The rest of it
There were 21 issues, enhancements, and bug fixes included in this release. A selection of these not mentioned above includes:
- SMTP debugging is now available in the Event Log rather than the System Log.
- You can now use
let/optionalchaining in your JavaScript when using the GraalJS lambda engine. - Some client library bugs were fixed.
- Email template size restrictions were increased from 64K to 16MB, allowing for inline images in emails.
- Windows installations now use WSL2 and a .deb file.
- FusionAuth now supports an expired
id_tokenin theid_token_hintfor the logout endpoint.
Read more about all the changes in the release notes.
Upgrade at will
The release notes are a guide to the changes, fixes, and new features. Please read them carefully to see if any features you use have been modified or enhanced.
If you’d like to upgrade your self-hosted FusionAuth instance, see our upgrade guide.
If you have a FusionAuth Cloud deployment, proceed to the “Deployments” tab on your account dashboard and upgrade your instances. If you have any questions about the upgrade, please open a support ticket.
Or, if we’ve piqued your interest and you’d like to use FusionAuth, check out your options.
