FusionAuth's cloud-hosted HA deployments run on AWS, meaning webhook requests will originate from AWS infrastructure.

Please open a support ticket for guidance on setting up firewall rules.

FusionAuth Cloud does not currently provide built-in analytics for MFA adoption. However, you can gather this data using the following approaches:

Retrieve Users with MFA Enabled Use the User Search API to retrieve all users for a specific application with MFA enabled. Here’s a sample queryString to retrieve all the users with an MFA configuration field. It may be empty, so you should check after retrieving them: _exists_:twoFactor Reference: Get All Users for an Application You should be able to combine these two queries to get what you want. Track New MFA Setups Per Day Set up a Webhook to listen for the user.two-factor.method.add event. This event fires when a user adds a new two-factor authentication method. Your backend can record these events daily for reporting purposes. Webhook Guide: Writing a Webhook

When upgrading FusionAuth, we recommend the following approach to ensure a smooth transition:

1. Review Release Notes

Each release may include breaking changes, bug fixes, and security updates. Be sure to check the release notes for any database migrations, template changes, or API modifications that may impact your environment. FusionAuth Release Notes

2. Choose an Upgrade Strategy

You can incrementally upgrade from 1.32.x → 1.42.x version-by-version or upgrade all at once. The recommended approach depends on your risk tolerance: Incremental Upgrades: Allows for testing each version before moving forward. Direct Upgrade: Faster but requires careful testing, especially if there are major changes.

3. Database Migrations & Maintenance Mode

FusionAuth automatically manages DB migrations in maintenance mode or silent mode. If you are using advanced configurations, refer to the manual upgrade process to apply database migrations carefully. FusionAuth Advanced Installation Guide

4. Testing in a Staging Environment

Before upgrading production, test the new version in a staging environment to verify that: All integrations (e.g., authentication flows, webhooks, APIs) function as expected. Templates render correctly (in case of UI or email template updates). Database migrations do not introduce issues.

5. Backup & Rollback Plan

Before upgrading, take full database and configuration backups in case a rollback is needed.

By following these best practices, you can minimize risks while upgrading to the latest version.

Existing Role Limitations in FusionAuth FusionAuth provides predefined Admin UI roles, which are not modifiable. You can review the available roles here:
FusionAuth Admin UI Roles The default FusionAuth application roles cannot be changed, which means read-only roles are not currently available. Requesting Read-Only Roles as a Feature FusionAuth does not currently support read-only access roles for applications or tenants. The likely reason for this is that users who need to view application/tenant properties often also need to update them. However, you can submit a feature request to suggest adding read-only roles:
Submit a Feature Request Workaround: Implement a Custom Read-Only View

If immediate read-only access is required, consider:

Using the FusionAuth APIs to create a custom dashboard where users can view but not edit data. Relevant APIs for this purpose: Application API Tenant API

Summary

No built-in read-only roles exist for applications or tenants. FusionAuth Admin UI roles are not modifiable. You can request read-only roles as a feature via GitHub. A workaround is to build a custom, API-based read-only view.

This behavior is a result of session management at the identity provider level (Azure AD), not FusionAuth. When federating authentication to an external IdP, FusionAuth does not control how sessions are managed within that IdP—Azure AD determines session persistence and re-authentication policies.

Why This Happens:

When UserA logs out of your application, their Azure AD session remains active unless explicitly ended. When UserB attempts to log in, Azure AD automatically reuses the existing session (UserA’s session) instead of prompting for new credentials. Since FusionAuth relies on the identity assertion from Azure AD, it issues a token based on the session provided by Azure AD, resulting in UserA’s credentials being used.

How to Prevent This:

1. Ensure Proper Logout from Azure AD

When logging out a user, also log them out from Azure AD to end their IdP session. This is typically done by redirecting the user to Azure AD’s logout URL during the sign-out process.

Example for Microsoft Entra ID (formerly Azure AD):

https://login.microsoftonline.com/common/oauth2/logout?post_logout_redirect_uri={your-app-logout-url} This ensures that UserA is fully logged out before a new user attempts to sign in.

2. Disable "Keep Me Signed In"

Many IdPs, including Azure AD, offer a "Keep me signed in" option. If the machine is shared, instruct users not to enable this option, as it maintains the session even after closing the browser.

3. Enforce Re-authentication

Some IdPs provide settings to force authentication on each login attempt.
*In Azure AD, you can modify your SSO session policies to require fresh authentication after logout or in specific conditions (e.g., IP changes, new browser sessions).

If your application requires frequent user switching, consider enforcing authentication via the prompt=login parameter in the Azure AD authentication request:

https://login.microsoftonline.com/{tenant_id}/oauth2/authorize?prompt=login

Summary

FusionAuth trusts the session response from Azure AD, so this issue must be resolved at the IdP level. Logout must also happen at Azure AD, not just your application. Session settings in Azure AD should be configured to ensure proper user switching. For shared devices, instruct users not to use "Keep me signed in."

For more details, refer to Azure AD’s session management documentation or configure logout redirects properly within your FusionAuth setup.

Yes, FusionAuth provides this information via the authenticationType claim in the JWT. This claim indicates the authentication method used, such as PASSWORD, GOOGLE, SAML, etc.

How to Access Authentication Type:

From the JWT: The authenticationType claim is included in the JWT access token. Documentation: JWT Access Token Claims From a Webhook Event (Alternative Approach): The same authenticationType value is included in the user.login.success webhook event. This may be useful if your system processes authentication events via webhooks instead of decoding JWTs. Documentation: User Login Success Webhook

For additional details on JWT structure and claims, refer to: JWT Components Explained

This is due to non-ASCII characters in headers causing an issue in the FusionAuth parsing code. Cloudflare sends headers with non-ASCII characters (such as cf-region: São Paulo) which triggers this issue.

This is a java-http bug that was fixed in 2024, and released in FusionAuth version 1.51.2.

So, two options:

upgrade to a version of FusionAuth 1.51.2 or newer. This is the recommended approach, but may require some work. as an interim workaround, you can disable the "Add visitor location headers" option from your CloudFlare console. This should not have any negative impact, since we do not inspect those headers.

@valerii15298 said in can't use fusion auth react sdk when fusion auth server runs locally on fusionauth.localhost::

I followed react sdk example https://github.com/FusionAuth/fusionauth-quickstart-javascript-react-web/tree/main

I changed in kickstart tenant issuer to

"issuer": "http://fusionauth.localhost:9011"

and variables to

"allowedOrigin": "http://fusionauth.localhost:4000", "authorizedRedirectURL": "http://fusionauth.localhost:4000", "authorizedPostLogoutURL": "http://fusionauth.localhost:4000/logged-out", "authorizedOriginURL": "http://fusionauth.localhost:4000", "logoutURL": "http://fusionauth.localhost:4000",

and started fusion auth in docker compose, also specified env var:

FUSIONAUTH_APP_URL=http://fusionauth.localhost:9011

For react sdk use this config:

const config: FusionAuthProviderConfig = { clientId: "e9fdb985-9173-4e01-9d73-ac2d60d1dc8e", // even started my app under the same local domain redirectUri: "http://fusionauth.localhost:4000", postLogoutRedirectUri: "http://localhost:4000/logged-out", // serverUrl: "http://localhost:9011", // this one works serverUrl: "http://fusionauth.localhost:9011", shouldAutoFetchUserInfo: true, shouldAutoRefresh: true, onRedirect: (state?: string) => { console.log(`Redirect happened with state value: ${state}`); }, scope: "openid email profile offline_access", };

And when I log in and am redirected back to my app, fusion auth hook does not show me that I am logged in(it does not even send any requests I checked network). But when I strip everywhere fusionauth. prefix then everything works fine. Why does not fusion auth work locally with custom domains?

Cookies on my local app fusionauth.localhost:4000 are also saved after I logged in: https://freeimage.host/i/3FVbSJsWacky Flip

And when I click login button again (or invoke startLogin function from useFusionAuth hook) I am redirected right away to the app since I am logged in. But isLoggedIn is false and useFusionAuth hook does not recognize that user is logged in.

(I have mapped fusionauth.localhost to localhost in my hosts file locally)

#docker #react-sdk

Set SameSite=None; Secure explicitly on the FusionAuth Cookie: this tells the browser to send the cookie with all requests, even cross-site requests. SameSite=None requires the Secure attribute, meaning the cookie will only be sent over HTTPS. Since you are using http://, this won't work directly without HTTPS set up locally.