Announcing FusionAuth 1.28

We’re excited to announce the release of version 1.28 of FusionAuth. This shipped on June 7, 2021, with follow on point releases planned shortly. This version resolves issues for FusionAuth community members and customers on versions 1.27 and older.

This release contained a number of enhancements and bug fixes. Please see the release notes for a full breakdown of the changes between 1.27 and 1.28. There were a few items I wanted to highlight.

Identity linking

Previous to this release, whenever a user authenticated via a third party identity provider, there were a few limitations:

• The identity provider needed to provide an email address.
• A user account would be created in FusionAuth if they didn’t exist.
• If a user account with the email address provided by the IdP existed in the tenant, the user would be associated with that account.

With account linking, the above limitations are removed. You can create an identity provider configuration with different behavior. There is now a link between an identity and a user, where before they were treated as a single entity.

Configuration options include:

• An anonymous link: always create a link based upon the unique Id returned by the identity provider. A username or email is not required and will not be used to link the user.
• Create pending link: do not automatically link, instead return a pending link identifier that can be used to link to an existing user.
• Link on email, create the user if they do not exist: a user will be created with the email returned by the identity provider if one does not already exist. This is the previous behavior and is the backwards compatible choice.
• Link on email, do not create the user if they do not exist: only link to an existing user based upon email. A user will not be created in FusionAuth if one does not already exist with email returned by the identity provider.
• Link on username, create the user if they do not exist: link to an existing user based upon username. A user will be created with the username returned by the identity provider if one does not already exist.
• Link on username, do not create the user if they do not exist: only link to an existing user based upon username. A user will not be created if one does not already exist with the username returned by the identity provider.

Linking by username has a greater risk of account takeover and therefore should be used with caution. In most cases, you would never want to enable more than one identity provider to link by username because there could be a username collision. Once a link has been created between the external identity provider and FusionAuth, the linking strategy doesn’t apply to future logins.

You can configure linking options for every identity provider except for HYPR. This feature is included in the community edition.

New identity providers

Speaking of identity providers, this release includes quite a few. The new identity providers available in FusionAuth version 1.28 include:

• Epic Games
• Nintendo (not included in 1.28.0, but planned for a patch release)
• Sony PlayStation Network
• Steam
• Twitch
• Xbox

If you are building a game and want to easily integrate with gaming platforms to ease the friction of user registration or login, we have you covered. Using these gaming specific identity providers is a Reactor feature, requiring a paid license.

A lambda for the Client Credentials grant

Finally, last but not least, the Client Credentials grant can execute an optional lambda before returning a token. FusionAuth lambdas are user provided logic which executes at certain points in FusionAuth workflows.

This lambda can be used to modify claims in the JWT generated by a Client Credentials grant. It’s similar to the JWT populate lambda, but has access to the Entities involved in the grant request, rather than the user.

Here’s the function signature of this lambda:

// Using the two Entity and permission parameters you can populate a client credentials grant JWT.
function populate(jwt, recipientEntity, targetEntities, permissions) {
  //...
}

At present, lambdas are configured at the tenant level and can be assigned by the API or UI. When using the administrative user interface, navigate to the “OAuth” tab. The Client Credentials grant is a Reactor feature, requiring a paid license.

Other improvements

Some of the other enhancements included in this release are:

• A reindex API is available. This API rebuilds the Elasticsearch index.
• The Email Send API now allows an email address in the To field instead of requiring FusionAuth user Ids. You can now use the FusionAuth templating system to send an email to anybody, not just users stored in FusionAuth.
• The SAML identity provider supports any NameID format, including urn:oasis:names:tc:SAML:2.0:nameid-format:persistent, used by Slack.
• The Google and Facebook identity providers can be configured to use either a popup or redirect style login flow. With the redirect style flow, you can use the idp_hint parameter to send users directly to Google or Facebook.

There’s a lot more in this release. In total, I counted 18 GitHub issues resolved in the 1.28 release.

Upgrade at will

The release notes are a guide of the changes, fixes, and new features. Please read them carefully to see if any features you use have been modified.

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 servers. 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.