@mark-robustelli
Sometimes user sees this:

e964a7be-6e0c-4ea2-aba0-82adf7f37b26-image.png

@eakpan Awesome, thanks for posting. This may end up helping others. Glad you are able to configure FusionAuth to work for you.

@laurahernandez I hope you are able to achieve the look and feel you are going for. I understand you would like to be able to show and hide the password dialog in simple themes and you are not the only one. Please be sure to upvote the issue here.

I understand using advanced themes may require more work, but ultimately it is more flexible that simple themes. Good Luck.

@mark-robustelli said in Logout with multiple subdomains fnaf:

@ext_figuvini this is an interesting use case. I would think the way you have it configured would work. I would have to recreate you situation to test. Unfortunately it may be a while before I can get that done. I should be able to take a look next week. If anyone has experience with this, please feel free to chime in.

Make sure to set the Redirect URIs in the application settings to include all relevant subdomains (e.g., https://backerstats.localhost/, https://pokerstats.localhost/).

@mark-robustelli Yes, it's all working. After the logout flow executes, the sessions that were being left behind on FusionAuth are now being revoked properly. Thanks.

@mark-robustelli

Thank you for the quick reply.

By "Also start the authorization process there?" I mean manually open a new tab for my application and clicking on "Login" which redirects to "/oauth2/authorize". So the same login process initiated twice in different tabs, then introducing login credentials on the first one.

The debug doesn't shed any light I'm afraid. The problem seems to be the "saml.csrf" cookie changing it's value across tabs.

@atakan thanks for sharing the information.

Yes—using FusionAuth access tokens to secure partner-facing APIs is a solid approach. The key is ensuring the tokens contain the right claims to enforce proper authorization for your endpoints.

Separating partners into a different tenant or application can improve security and simplify management. Different tenants fully isolate users and tokens, but would require duplicating application configs. Alternatively, you could keep partners in the same tenant and distinguish them via roles, claims, or separate applications.

If partners are accessing APIs server-to-server, the client credentials grant (Entities in FusionAuth) is the correct choice. Be sure to carefully scope each partner’s access to avoid over-permissioning.

More on these topics:

API Authorization with FusionAuth Tenants Overview JWT Anatomy Authorization Models

Yes—you can safely add a fourth custom URL. The “replace” label appears because the system expects you to submit the entire list of domains each time. To avoid losing any URLs, make sure all four domains—including your existing three—are entered in the form before you submit. Only custom domains omitted from the list will be removed.

More details here:
Updating Custom Domains

Yes! FusionAuth stores MFA details on the user object, and you can search for users with MFA enabled using Elasticsearch queries.

For example, in the Admin UI’s User search, you can run:

_exists_:twoFactor

This returns all users with at least one MFA method configured. You can also perform similar searches via the User Search API to build custom reports. For more details on searchable user fields and Elasticsearch queries, see:

User Fields Reference User Search with Elasticsearch

This is definitely an uncommon scenario, so there’s no out-of-the-box flow documented for it, but here’s one way to handle it:

Create a second Google IdP: FusionAuth supports only one native Google IdP, but you can set up an additional Google connection as a generic OpenID Connect (OIDC) IdP. This second IdP can request the elevated scopes you need for email access. See the OIDC docs here: OpenID Connect IdP in FusionAuth. Trigger reauthentication: When a user opts into the email client feature, redirect them through the second IdP’s OAuth flow to acquire the elevated scopes. This effectively escalates their session without forcing all users through additional authentication unnecessarily.

This approach allows you to avoid reauthentication for users who don’t need the extra scopes while supporting a higher-privilege flow for users who do.

Great question—this often causes confusion.

In FusionAuth, logging in after a Forgot Password flow is tracked as ONE_TIME_PASSWORD. That’s because, technically, FusionAuth uses a one-time password during that process. For example, if you look at the Change a User’s Password API, it returns a one-time password token. On the hosted pages, FusionAuth automatically consumes this token to sign the user in immediately after they reset their password via the forgot password link in their email.

So even without traditional OTP or MFA configured, these login events can appear as ONE_TIME_PASSWORD due to password reset flows.

Good question—it’s a common challenge.

By default, the email verification flow breaks the OAuth/PKCE context because the user leaves the registration page to check their email and clicks a verification link. FusionAuth can’t continue the OAuth flow automatically from that email link, which is why your hard-coded redirect URI fails without the required OAuth code.

A better solution is to switch your email verification strategy from Clickable Link to Form Field (under Tenant → Email → Email Verification → Verification Strategy). With this approach, users stay on the original registration page, enter the verification code from their email, and the OAuth/PKCE flow remains intact—including the authorization code. This enables seamless redirecting back into your app after verification.

If you’re creating and registering users for an application at the same time, remember to also check the app-level registration verification settings under:
FusionAuth Admin UI → Applications → Edit Application → Registration tab.

More details are in the docs: Registration Email Verification

You’re correct that user_support_manager is the right role, but it has a limitation: it can only remove MFA devices if the manager has the user’s MFA code or recovery codes. Only admins can disable MFA without those.

If you want to remove MFA without needing a code, you’d need to use the User API to clear the user’s MFA data. Also, confirm that both support managers have the same role assigned under their registrations in the FusionAuth application. Check this under each user’s Source tab in the Admin UI under registrations.roles.

More details:

Update a User via API

FusionAuth Admin UI Roles

Yes, you can localize social login buttons, but it requires customizing your theme.

In the Theme Helpers file, locate the macro for each IdP button—for example, the Google button macro (starting around line 409). Change the text like this:

From:

<div class="text">${identityProvider.lookupButtonText(clientId)?trim}</div>

To:

<div class="text">${theme.message('google-login')}</div>

Then, define google-login in your Theme → Messages bundles for each supported language. Repeat the same process for the Apple button macro (starting around line 363).

This allows the social login button text to display localized strings based on the user’s selected language.

This error usually means FusionAuth doesn’t have the public key it needs to verify the JWT signature.

Make sure you’ve imported the public key that Keycloak uses to sign tokens into Settings → Key Master in FusionAuth. Check whether your JWT includes a kid (Key ID) claim. If it does, the key you import into Key Master must have a matching Key ID. You can confirm the Key ID after importing by clicking the view (🔍) icon next to the key.

Once the correct key is imported and matches the kid from the JWT, FusionAuth will be able to verify the token’s signature.

FusionAuth doesn’t currently support setting a default IdP for an application or automatically forcing logins through an IdP. You’re welcome to submit a feature request on our GitHub issues page.

If all your users share the same email domain, you could try Managed Domains to route them to the correct IdP.

Another option is to place a proxy in front of FusionAuth. The proxy could inspect incoming requests and append the idp_hint before forwarding traffic to FusionAuth. You can learn more about using a proxy setup here.

Data transfers between FusionAuth deployments aren’t typically included as a standard service, except in cases where a business is scaling up to a larger deployment. However, since this is a new production setup, we can accommodate a one-time migration for you. The process would result in about 10 minutes of downtime.

Make sure you have a master API key on hand, as certain settings—like SMTP configurations—might need to be updated manually after the transfer. Alternatively, you’re welcome to migrate the configuration manually if you prefer.

For Business hosting, FusionAuth creates daily database snapshots around midnight Mountain Time. Three days’ worth of backups are kept. Additionally, a snapshot is taken before any FusionAuth software upgrade and retained for 30 days. Direct database access isn’t available on hosted deployments, so you can’t create traditional database backups yourself. However, most user and configuration data can be retrieved via the FusionAuth API. Some sensitive data, like password hashes or one-time codes (MFA, email verification, magic links), cannot be extracted. Yes — upgrades from Basic to Business or Business to High Availability are possible. A FusionAuth support team member coordinates the process, which typically takes 60–90 minutes and may involve up to 45 minutes of downtime. New deployments use our updated infrastructure, which offers additional features. Downgrading FusionAuth is technically possible but complex and rare. It requires manual intervention by FusionAuth support and can involve significant effort. Downgrades requested within 30 days of an upgrade are simpler and involve less disruption, but the exact downtime is difficult to estimate. Yes — Basic hosting now supports a single custom domain on the new infrastructure. We can help migrate your deployment to the newer model, enabling you to add a custom domain for easier integration. Yes — it’s possible to change your current hosted URL when migrating to the new infrastructure.

More details on hosting plans and capabilities are available here: https://fusionauth.io/docs/get-started/run-in-the-cloud/

You’re correct — when duplicating a tenant, FusionAuth does not copy the SMTP password. This is by design for security reasons. Passwords are stored securely and aren’t exposed in logs, debug output, or the UI, even with debug logging enabled for email.

Unfortunately, there’s no way to automatically carry over the SMTP password when duplicating tenants, and there aren’t plans to change this behavior.

You’ll need to manually re-enter the SMTP password in the duplicated tenant’s configuration.