How to share SSO session between two applications in the same tenant?

FASupportBot — Invalid Date

Yes, you need to create two separate applications within the same tenant in FusionAuth. Here's how to configure this:

Configuration Steps

Create both applications in the same tenant - Users are scoped at the tenant level, so applications in the same tenant can share authentication state through FusionAuth's SSO session.

Enable self-service registration on the second application - This ensures a seamless login experience. When a user navigates to the second application while already authenticated to the first, they will be automatically registered and logged in.

How It Works User logs into the first application at your registration URL to create their account. Make sure the rememberDevice parameter is true or checked. You can modify your theme to hardcode that value. While that session is valid, they navigate to the second application's login URL They are automatically registered and authenticated to the second application without manual intervention

The key to this working is that FusionAuth creates an SSO session at the tenant level when a user logs in and rememberDevice is checked. When the authenticated user tries to access the second application, FusionAuth recognizes the existing SSO session and automatically creates a registration for that user in the second application (when self-service registration is enabled).

Password Reset Behavior

Because users are scoped at the tenant level, a password reset applies to all applications under that tenant. Users can utilize the password reset page for the first application and will be able to log in at the second application with the new password.

Sharing Templates

Both applications can share the same theme and templates. Themes are assigned at the tenant level (though you can also assign application-specific themes if needed starting with FusionAuth 1.27+). This means you can configure one set of templates - including password reset, login, and user management pages - that will be used by both applications.

Pre-creating User Accounts

If you create user accounts ahead of time, you can automatically include the registration for the second application when creating the users. This would mean adding that application to their registrations when you create the account initially using the Create a User and Registration API.

Related Documentation Implementing Single Sign-On - Complete guide to configuring SSO between applications Self-Service Registration - How automatic registration works when SSO is enabled Create a User Registration API - Programmatically register existing users to additional applications Application Themes - Configure application-specific themes if needed Themes Documentation - Customize and share login pages and templates across applications

Why does using a recovery code to remove one MFA method delete all MFA methods?

FASupportBot — Invalid Date

Yes, this is intentional behavior in FusionAuth.

When a user provides a recovery code to disable an MFA method — whether through the hosted pages or the API — FusionAuth removes all MFA methods from the account. The hosted pages use the same underlying MFA API, so the behavior is consistent across both interfaces.

Why does this happen?

Recovery codes are designed as a last-resort mechanism. The assumption is that if a user must resort to a recovery code to disable MFA, they may have lost access to all their authentication factors. Removing all MFA methods ensures the user can regain access and re-enroll fresh methods.

When a recovery code is used for disabling MFA:

All MFA methods are removed from the user's account, regardless of which specific methodId was targeted All remaining recovery codes are invalidated at the same time If the user later adds a new MFA method, a brand new set of recovery codes will be generated Why is login different?

When a user logs in with a recovery code (instead of a verification code), FusionAuth only consumes that specific recovery code without removing MFA methods. This is because login is not an administrative action — the user is simply authenticating, not managing their MFA configuration.

Current limitations

Unfortunately, there is currently no way to configure FusionAuth to remove only the targeted MFA method when a recovery code is used. This is a known design constraint.

Workaround considerations

If this behavior is problematic for your use case, you could:

Provide clear messaging to users before they use a recovery code to disable MFA Implement a custom flow outside the hosted pages that uses the API with tighter control over which methods are removed Encourage users to contact support or use an alternative recovery flow that doesn't rely on recovery codes for MFA management

Feedback on this behavior has been passed along to the FusionAuth Product team for future consideration.

Related Documentation Multi-Factor Authentication (MFA) - Disable MFA Guide - Explains the behavior when using recovery codes vs. verification codes to disable MFA Disable Multi-Factor API - API documentation for disabling MFA methods Recovery Codes Overview - Information about MFA recovery codes and when they're generated Self-Service Account Management - Documentation on the hosted account management pages including MFA management

Topics tagged with multi

How to share SSO session between two applications in the same tenant?

Why does using a recovery code to remove one MFA method delete all MFA methods?