Frequently Asked Questions (FAQ)

Troubleshooting Blank FusionAuth Login Pages in Android WebViews on Specific Devices

wesley — Thu, 01 Jan 2026 04:06:32 GMT

This is indeed unusual, especially since the issue appears to affect only a single user and device, which makes a FusionAuth configuration issue unlikely.

A few things to check and try:

Open in External Browser Ask the user to tap the three-dot menu (if available) in the webview and choose “Open in Chrome” or their default browser. If the page loads correctly there, the issue is likely related to the embedded webview rather than FusionAuth itself.

WebView / Browser-Specific Issues

Some Android devices (including certain Xiaomi models) ship with custom WebView implementations or aggressive privacy/security settings that can interfere with embedded web content.

Ensure the device has the latest Android System WebView and browser updates installed.

Domain / CNAME Edge Cases

There have been rare cases where mobile browsers or webviews behave unexpectedly if the domain includes characters such as underscores (_) or dashes (-) in certain positions.

While this typically results in explicit errors (like “Address not found”), it’s still worth reviewing your domain and CNAME setup—especially since you’re self-hosting.

Given that the login works for the same user on other devices, this is most likely a device- or WebView-specific issue rather than a problem with FusionAuth itself. If opening the login page in a full browser works, that should help narrow the root cause to the embedded webview implementation on that device.

Calling AWS API Gateway with SigV4 from FusionAuth Lambdas: Limitations and Recommended Architecture

wesley — Thu, 01 Jan 2026 03:57:27 GMT

You’re correct: FusionAuth’s Lambda environment does not provide access to external libraries (including AWS SDKs or SigV4 helpers), and there is no secure secrets store available to Lambdas. That means if you need AWS SigV4 signing from inside a Lambda, you would have to implement the signing logic yourself and embed any required credentials directly in the Lambda code—this is generally not considered secure.

Also, if you are using FusionAuth Cloud, you cannot place Lambdas into your private network (for example, the same VPC/network as your API Gateway), so that option isn’t available in hosted deployments.

If you need this capability, the recommended approach is typically to move the signing and secret handling into a system you control (for example, a backend service that FusionAuth calls), rather than performing SigV4 signing directly in a FusionAuth Lambda.

Related issue tracking:
https://github.com/fusionauth/fusionauth-issues/issues/1629

Why Webhook Transaction Settings Are Greyed Out in FusionAuth Cloud for User and Registration Events

wesley — Thu, 01 Jan 2026 03:38:55 GMT

This is a known bug, and it looks like the underlying issue has already been identified and fixed. The fix will be included in the next FusionAuth release.

How to Enforce Customer-Specific Session Lifetimes and Fast Deprovisioning for Federated Users in FusionAuth

wesley — Sat, 20 Dec 2025 02:14:41 GMT

There are a couple of overlapping layers here.

Access tokens aren’t revocable by default
Access tokens (JWTs) are self-contained. Once issued, they remain valid until they expire unless you implement a custom revocation strategy (such as token blacklisting). FusionAuth covers one approach here:
https://fusionauth.io/articles/tokens/revoking-jwts
So if your access token lifetime is 600 seconds, a disabled user could continue to access APIs until that token expires (up to ~10 minutes) unless you add an additional revocation layer.

FusionAuth sessions are typically independent from the IdP
Once the upstream IdP authenticates the user, FusionAuth generally maintains its own session state. If a user is disabled in the upstream IdP, that does not automatically invalidate FusionAuth sessions or prevent refresh token usage.
So yes, depending on your implementation, a user can potentially continue to operate in FusionAuth even if they are disabled upstream, until you either:

expire/stop honoring their tokens, or remove/disable the user in FusionAuth, or enforce additional checks at login/session refresh time.

Options to meet “disabled within 300 seconds” for one customer
If you need disablement to take effect quickly without shortening sessions for everyone, you generally need an integration that pushes the disablement signal into FusionAuth (or into your resource servers).

A. SCIM (best fit when the customer maps cleanly to a tenant)
If your customer can be logically isolated (e.g., “customer A users live in tenant A”), SCIM is a strong option. The customer’s IdP can provision/deprovision users into FusionAuth, and a disable/delete action can remove their FusionAuth access (including sessions). This is the cleanest approach when tenant segmentation is possible.

B. Event-driven deprovisioning (IdP → your service → FusionAuth API)
If the customer’s IdP can emit events (user disabled/deprovisioned), you can build a lightweight integration that:

receives the IdP event, then disables or deletes the corresponding user in FusionAuth via API.

Once the user is disabled/deleted in FusionAuth, they won’t be able to continue normal authentication flows.

C. Token revocation strategy (resource server enforcement)
If the requirement is “deny access within 300 seconds,” the most deterministic way is to enforce it at the API/resource-server layer by:

using short access-token lifetimes (<= 300 seconds), and/or adding token blacklisting / introspection-style checks in your APIs.

This avoids relying on refresh token expiration to enforce disablement.

About limiting refresh token lifetime per customer

A reconcile lambda can help with user provisioning and claims, but it won’t reliably solve the core issue of existing sessions and refresh tokens already issued. There isn’t a simple “per-customer refresh token TTL override” you can apply after the fact without an architectural approach like the ones above.

Why FusionAuth SAML Metadata Always Sets WantAssertionsSigned to False

wesley — Sat, 20 Dec 2025 01:55:46 GMT

At this time, FusionAuth does not support changing WantAssertionsSigned to true in the generated SAML metadata. This value is hard-coded and cannot be modified through IdP configuration or other settings.

From a practical standpoint, this should not impact security or standards compliance. FusionAuth signs the entire SAML response using the verification key configured in the IdP. Since the assertion is part of the signed response, signing the assertion itself would be redundant and is not required by the SAML specification.

If your client strictly requires WantAssertionsSigned="true" due to a non-standard or legacy implementation, this would need to be addressed on the Service Provider side, as FusionAuth cannot currently emit metadata with that value set to true.

Why You Can’t Create New Hosted Instances in the FusionAuth Account Portal on Invoiced Billing

wesley — Mon, 15 Dec 2025 04:00:54 GMT

You’re correct—there is no fixed limit on the number of hosted FusionAuth instances you can have.
However, since your account is on invoiced billing, new hosted deployments cannot be created directly through the Account Portal. That functionality is only available for self-serve billing accounts.

Next Steps

Our Customer Success team will reach out to you via email. They’ll help provision the additional non-production instances and add them to your existing order.

Once that’s complete, you’ll have access to the new hosted deployments without needing to manage them through the portal yourself.

How to Authenticate API Clients and End Users in the Same FusionAuth Tenant Using Entities

wesley — Sat, 13 Dec 2025 02:35:50 GMT

Yes, you can mix API clients and end-user logins within the same tenant. Tenant-level controls such as MFA do not prevent this when the authentication flows are properly separated.

Recommended Approach: Use Entities for API Clients

The most common and recommended pattern is to use Entities for API authentication:

End users authenticate using the Authorization Code grant, which can enforce MFA and other user-facing security requirements. API clients authenticate using the Client Credentials grant via Entities. Because these are different OAuth grants and flows, tenant-level requirements like MFA apply to users but do not apply to API clients using client credentials.

This allows both authentication types to coexist cleanly within the same tenant while maintaining appropriate security boundaries.

Cost and Licensing

There are no additional licensing or cost implications for using this approach:

Entities and the Client Credentials flow are included in FusionAuth plans. API clients authenticated via Entities do not count as end users for MAU-based billing.

Additional Resources

These resources provide detailed guidance and examples:

API Authorization with FusionAuth Entity Management Concepts Using Entities for API Authorization (Video)

This setup is widely used and should cover your use case well.

How to Retrieve Last Login Dates for Multiple Users in FusionAuth via the Search API

wesley — Sat, 25 Oct 2025 02:07:30 GMT

FusionAuth doesn’t support uploading a CSV to retrieve last-login timestamps. However, you can do this efficiently with the Search for Users API and return lastLoginInstant for many users at once.

How to do it (batch via API)

Use the User Search endpoint
POST /api/user/search (set your X-FusionAuth-TenantId and Authorization headers).

Send an Elasticsearch query using terms to match a batch of emails/usernames, and read lastLoginInstant from each returned user:

{ "search": { "query": "{\"terms\":{\"email\":[\"a@example.com\",\"b@example.com\",\"c@example.com\"]}}", "numberOfResults": 500, "startRow": 0 } } Swap email for username if that’s what you have. If your list is large, chunk it (e.g., 200–500 logins per request) and paginate with startRow / numberOfResults. (Optional) Filter by last-login date with a range query on lastLoginInstant: { "search": { "query": "{\"range\":{\"lastLoginInstant\":{\"gte\":\"2025-10-01T00:00:00Z\"}}}" } }

You can also query by epoch millis if you prefer.

Map results
Each user object includes lastLoginInstant (epoch millis). Convert to your desired timezone/format in your script and write out a CSV.

Tips

If you need all users in a tenant (not just your list), you can search with a wildcard or a match-all query and page through results, then filter locally. For ongoing metrics, consider subscribing to user.login.success webhooks and recording last logins as they happen.

Docs:

Search for Users API (Elasticsearch): https://fusionauth.io/docs/apis/users#elasticsearch-search-engine

How to Fix 'could not find memberId' Errors When Removing Group Members in FusionAuth

wesley — Fri, 24 Oct 2025 01:13:12 GMT

You can work around this by passing the IDs directly in your request. Here’s an example of how to structure the request correctly:

from fusionauth.fusionauth_client import FusionAuthClient api_key = 'your-fusionauth-api-key' base_url = 'https://your-fusionauth-instance.com' group_id = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' user_ids_to_remove = [ 'yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy', 'zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz' ] client = FusionAuthClient(api_key, base_url) member_delete_request = {'members': {group_id: user_ids_to_remove}} response = client.delete_group_members(member_delete_request) if response.was_successful(): print("Successfully removed users from group!") else: print(f"Error: {response.error_response}")

This approach correctly formats the request for the API to process and delete the specified users from the group.

How to Fix Missing End-of-Month Data in FusionAuth Daily Active Users and Registrations

wesley — Wed, 22 Oct 2025 00:54:10 GMT

This issue was addressed in version 1.56.0. Make sure your FusionAuth instance is updated to the latest version, as several reporting-related fixes have been released that resolve this specific problem.

How to Monitor FusionAuth Cloud with Datadog (via Prometheus) and Track 2FA Drop-Off

wesley — Thu, 18 Sep 2025 13:13:08 GMT

You cannot integrate Datadog directly into the cloud-hosted version of FusionAuth. The only relevant section in the documentation is "Use Datadog Agent on a Remote Host." This requires setting up Datadog to monitor FusionAuth using the Prometheus Metrics API endpoint. For monitoring failed 2FA rates, FusionAuth does not currently have built-in support. There is no webhook for failed MFA, but you can use the failed login webhook to monitor incorrect password attempts.

Retrieve system metrics using Prometheus
Use the Datadog Agent on a remote host
User login failed webhook

Configuring Proofpoint Cloud with FusionAuth SMTP

wesley — Sat, 13 Sep 2025 12:15:19 GMT

FusionAuth uses standard SMTP for all email connections. As long as Proofpoint Cloud supports a standard SMTP connection where FusionAuth sends transactional emails, initiates a handshake, and completes delivery, the integration will work. You can reference our documentation for details on configuring SMTP with common providers:

Configure Email

Using Separate Applications in a Single Tenant for AD/Entra ID and Client Authentication

wesley — Wed, 10 Sep 2025 01:11:07 GMT

You can manage both flows within a single tenant. Typically, you’d configure separate applications, one for the Admin portal tied to your AD/Entra ID provider, and another for your client-facing site using FusionAuth. You can then use login hints or managed domains to direct users to the correct Identity Provider (IdP).

Identity Provider Hints
Managed Domains

Creating Users Without SMTP: How to Manually Set Passwords in FusionAuth

wesley — Mon, 08 Sep 2025 11:14:28 GMT

Yes, you can create a user without SMTP configured. In the Admin UI, disable the Send Setup Password option and set the password manually during user creation. If you’re using the API, set "sendSetPasswordEmail": false and include a "password" field in the user object.

Users API

Safe Upgrade Guide: Moving from FusionAuth 1.54 to 1.59

wesley — Sat, 06 Sep 2025 22:21:00 GMT

During an upgrade, FusionAuth monitors your deployment, and if it becomes unresponsive for more than five minutes, the on-call engineer is alerted. A snapshot of the database is taken before the upgrade, so a rollback is possible, though it is manual and would result in data loss from the time of the upgrade to the rollback. Rollbacks are very rare and have only happened once in the past four years.

You can safely upgrade directly to 1.59, and many customers do skip versions. The upgrade process is straightforward: once started, the deployment status changes to Upgrading and returns to Active when complete. For production instances, downtime is minimal (typically seconds, if at all) because multi-node deployments use rolling upgrades. Most upgrades take under 20 minutes, though in rare cases they can take up to an hour.

FusionAuth never forces you to upgrade, but if you are running a very old version (1–2 years behind) and encounter issues, support may request that you upgrade before troubleshooting.

Upgrading a Deployment

How to Replace Arrays with PATCH in FusionAuth Using application/merge-patch+json

wesley — Sat, 09 Aug 2025 03:51:12 GMT

Good question. I believe this is due to how we implemented our PATCH calls. If you are making a straight API call, you can change the Content-Type header to application/merge-patch+json which will instead overwrite the existing array with whatever you have provided. That's the most straightforward way to replace array values. There are other methods detailed in the doc below but those involve removing values one by one instead of just overwriting them. The downside here is that I don't believe Client Libraries usually support the merge-patch header.

https://fusionauth.io/docs/apis/#the-patch-http-method

Custom Registration Fields Missing for Social Logins – Why You Should Listen for registration.update Events

wesley — Sat, 09 Aug 2025 03:48:03 GMT

If you believe that you have discovered a bug or issue with FusionAuth, please log an issue below.

https://github.com/FusionAuth/fusionauth-issues/issues/new/choose

To note, you will likely want to be listening to the registration.update webhook for changes to the registration object prompted by additional fields the user needs to have completed based on what is a required field for self service registration.

In the case of a user entering all these fields "manually" (as part of a registration form) we will create the user and the registration at the same time (thus transmitting all information, including all required registration fields, as part of the user.create and registration.create events).

However, in the case of a social login, the user and registration will be created after the IdP provider returns information via the user.create and registration.create events. Additional registration will be asked of the user as part of the complete registration process (if there are additional required fields) and that additional information will be transmitted as part of the registration.update event.

https://fusionauth.io/docs/extend/events-and-webhooks/events/user-registration-update

Why FusionAuth Doesn’t Support the SAML ‘Transient’ NameIDPolicy

wesley — Sat, 09 Aug 2025 03:45:51 GMT

The transient policy is not something FusionAuth will support for the SAML NameID policy. From the SAML standards doc, a transient NameID is supposed to be a temporary value which is not a good basis to build a link between two identity systems on. That is the main reason FusionAuth does not support this policy as it would likely lead to issues later down the line with the Identity Provider. Apologies for the inconvenience but having the User ID/UUID shift or change would cause problems as FA relies on a consistent User ID/UUID(NameID) to make a SAML link work.

http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

Airgapped License Still Connecting to reactor.fusionauth.io – Can It Be Disabled?

wesley — Sat, 09 Aug 2025 03:42:55 GMT

Currently, there is not a way to turn it off. Our air gapped license is still going to try to make that call out to us, but that won't cause any issues. The difference being that a normal license would have issues if it could not "phone home" back to us whereas the air gapped license won't have issues but it will still try to make those calls.

How to Change Fonts in the FusionAuth Hosted Login Page

wesley — Sat, 09 Aug 2025 03:40:36 GMT

If you want to change the font on the hosted login page and the login experience users are offered through FusionAuth, then this can be changed via our Themes. Very likely you will want to update the CSS associated with the theme you are using for the FusionAuth Application/Tenant. Changes to the theme can be completed through this API: https://fusionauth.io/docs/apis/themes/advanced-themes.

Alternatively, you can use the Admin UI to make changes to your CSS as well.

Custom Domain and SSL Certificate Support in Basic Cloud Hosting

wesley — Sat, 09 Aug 2025 03:38:31 GMT

Yes with a Basic Cloud you get one custom domain and no backups, you would just need to update your DNS records to include our CNAMEs for this custom domain. You would submit your custom domain via the Hosting tab of the account.fusionauth.io under the Action Drop down. Then you will be shown the CNAME record for that domain and you will have to update your DNS records to include this CNAME. You can see an example of this at the doc below.

https://fusionauth.io/docs/get-started/run-in-the-cloud/cloud#custom-domains

You would not be able to use your own SSL certificates. We would handle all those in FusionAuth Cloud. We create the certificates on our end and you just need to create DNS records to validate the domain with the CNAME records.

How to Handle CAPTCHA and Rate Limits for Automated Testing in FusionAuth

james61972 — Sat, 09 Aug 2025 03:36:05 GMT

You’ll need to disable or mock CAPTCHA in a test environment and adjust rate-limit settings in FusionAuth’s config or use test API keys to avoid hitting production limits during automated runs.

How to Update user.data for a User in FusionAuth via API or Admin Forms

wesley — Sat, 09 Aug 2025 02:16:48 GMT

There are a few ways you can get what you need. You can either make these changes via the API and then they will be updated in the UI.

https://fusionauth.io/docs/get-started/core-concepts/users#user-data

https://fusionauth.io/docs/apis/users#update-a-user

Or you can do this using custom admin forms:

https://fusionauth.io/docs/lifecycle/manage-users/admin-forms

How to Find Your Reactor License ID and Use It with Kickstart in FusionAuth

wesley — Sat, 09 Aug 2025 02:13:37 GMT

The license ID is just the license key itself. You can grab your license here https://account.fusionauth.io/account/plan/. Each license will have a prod key and non-prod key, for testing you just need to grab the non-prod key and use that for your license ID in Kickstart.

https://fusionauth.io/docs/get-started/download-and-install/development/kickstart#set-your-license-id

How to Authenticate a Local React App with FusionAuth Hosted on Azure Without Cross-Origin Cookie Issues

wesley — Sat, 09 Aug 2025 02:09:15 GMT

If you are using the React SDK (which uses Hosted Backend: https://fusionauth.io/docs/apis/hosted-backend, then there are a couple options but they will all require some integration work from your end. The SDKs and Hosted Backend are designed to be easy to use and implement but they are not flexible as you can see with the cookies. Also I'm not sure if this was a consideration in the decision that running FusionAuth locally is not an option but just in case it was: You can use your FusionAuth non-production licenses wherever you want, we do not charge more "per deployment". So you can activate your non-prod license on a locally hosted FusionAuth instance in addition to your FusionAuth on Azure App Service, you can run your non-prod license on as many instances as you want.

Develop your application while hosting it on Azure App service so FusionAuth and the app are on the same domain

Setup a proxy for either your application or FusionAuth so they can be on the same domain

Documentation for setting up a proxy for FusionAuth: https://fusionauth.io/docs/operate/deploy/proxy-setup

Create your own Hosted Backend, example here: https://github.com/FusionAuth/fusionauth-javascript-sdk-express/tree/main

Similar to #3, instead of setting up a Hosted Backend use the OAuth2 endpoints directly. In this scenario you will also be responsible for doing the OAuth code exchange for a token then setting the token cookies on the browser as well as session management with these tokens.

https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/endpoints

https://fusionauth.io/docs/operate/secure/token-storage