Topics created by wesley

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.

FusionAuth does not provide a built-in way to specify a fixed IP address for outbound emails. However, you can determine the current IP of your deployment and update your SPF records accordingly.

Please open a support ticket for guidance on finding the IP address of a FusionAuth Cloud deployment.

Yes, this is expected behavior because access tokens cannot be revoked by default.

Why /oauth2/logout Doesn’t Invalidate Access Tokens:

Access tokens are stateless and do not require real-time validation with FusionAuth after issuance. For this reason, access tokens are typically short-lived, reducing security risks. Logout via /oauth2/logout only removes the SSO cookie and does not affect issued tokens.

How to Handle Token Revocation:

Use Short-Lived Access Tokens The recommended approach is to issue short expiration times for access tokens and rely on refresh tokens for continued access. Implement a Token Revocation Strategy If you need a way to invalidate access tokens, consider implementing a denylist-based revocation workflow. FusionAuth provides guidance on how to do this: Revoking JWTs in FusionAuth Ensure Full Logout by Removing All Session Identifiers If the user is also authenticated via a refresh token or other session identifiers, these must be explicitly removed to fully log out the user. FusionAuth provides more details in:
Logout Endpoint Documentation
User Sessions in FusionAuth

Summary

By default, access tokens remain valid until expiration, even after logging out. To ensure access is revoked immediately, you will need to either implement a denylist mechanism or rely on short-lived tokens with refresh token workflows.

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

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

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 does not currently support the UMA grant type or Token Exchange (RFC 8693).

However, we track feature requests and open issues on GitHub. Both have been requested features, and you can upvote the requests and/or add comments with your use cases to show interest:

GitHub Issue: UMA Support GitHub Issue: Token Exchange RFC

At this time, there is no confirmed ETA for implementing these features, but community interest plays a role in prioritization. Here’s more on our roadmap process.

Yes, this behavior occurs because creating a user via the API returns an access token, which indirectly updates lastLoginInstant.

Workarounds:

Use the Import API Instead The Import API allows you to create users without generating an access token, preventing the lastLoginInstant field from being updated. API Reference: Import Users API Track Logins Using Webhooks If lastLoginInstant is needed for business logic or reporting, consider tracking actual user logins via webhooks instead. FusionAuth provides user.login.* webhook events to capture real login activity. API Reference: User Login Webhooks

By using the Import API for user creation and webhooks for tracking real logins, you can avoid the unintended side effect of lastLoginInstant being updated upon user creation.

FusionAuth does not support configuring a read-only database, as most database interactions involve writes, particularly from login events.

For additional context on high-availability database configurations with FusionAuth, refer to this forum discussion:

Does FusionAuth Support High-Availability Database Configurations?

If read replication is critical for your setup, you may need to handle database routing at the infrastructure level (e.g., using a proxy like Pgpool-II for PostgreSQL or ProxySQL for MySQL) rather than within FusionAuth itself.

FusionAuth Cloud supports active/passive DR which is further outlined here. This may be helpful to you as you build out your high availability FusionAuth system.

Based on observed import speeds, 100,000 users take approximately 1-2 minutes to import.

Using this estimate, importing 5 million users could take about 50 to 100 minutes, depending on system performance, database speed, and network conditions.

If you are importing into FusionAuth Cloud, follow the steps here to add your importing system’s IP address to our allow list.

To assist with the migration process, FusionAuth provides import scripts:

FusionAuth Import Scripts

FusionAuth is compatible with Mailgun, and we have customers who have successfully integrated it. FusionAuth works with any email provider that supports SMTP configuration, so Mailgun should function correctly.

Troubleshooting Steps:

Verify SMTP Settings: Ensure your Mailgun SMTP credentials are correctly configured in Settings > Email within FusionAuth. Review FusionAuth’s Email Troubleshooting Guide: FusionAuth Email Troubleshooting Use SWAKS for Debugging: SWAKS (Swiss Army Knife for SMTP) can help diagnose SMTP issues by testing the connection between FusionAuth and Mailgun. Enable Debug Logging: Debug logs will provide more detailed information about what might be causing the issue.

These steps should help pinpoint the problem.

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.

JWTs Cannot Be Revoked: Once a JWT is issued, it remains valid until it expires. JWTs are decoupled authentication tokens, meaning they do not require continuous validation against a central authority. While OAuth2 includes a token introspection endpoint, it is only useful for access tokens and does not support JWT revocation. What the /oauth2/introspect Endpoint Does: This endpoint verifies whether an access token is valid based on its signature, expiration time, and format. It does not check whether a user’s account has been locked or disabled. Impact of a Locked Account on JWTs: If a user’s account is locked, they will not be able to obtain a new access token. However, any previously issued JWTs will continue to be valid until they expire, unless you implement additional measures. How to Handle JWT Revocation:
Since OAuth2 does not include JWT revocation natively, you can implement one of the following approaches: Use Short Token Lifetimes: Issue JWTs with short expiration times and rely on refresh tokens for continued access. Leverage Webhooks for Denylisting: Use FusionAuth’s event system to notify services when a user is locked or a token should no longer be valid. Services can then maintain a blacklist of invalidated JWTs.

For more details, refer to:

Revoking JWTs in FusionAuth

Yes, exchanging a refresh token for a new access token (JWT) does count as a login event in the Login report.

Events That Count as a "Login":

A login is completed using any Login API (e.g., normal login, one-time login, passwordless login, Identity Provider login, or Connector-based login). A user is created with a password (whether through self-service registration or the Registration API). A refresh token is exchanged for a new JWT. A user successfully completes a 2FA login.

For more details, refer to:
What Makes a User Active?

The initial API key created during setup is primarily intended for administrative use and API access. While it is not directly used within the FusionAuth UI, it can be used to authenticate API requests depending on the permissions granted to it.

Recommendations:

Keep an API Key for Emergency Access: It is advisable to retain at least one API key for break glass reasons—for example, to regain access in case of authentication issues. API Usage: API keys are commonly used to interact with FusionAuth’s REST APIs for various authentication and management tasks.

What Happens If You Delete It?

If no other API keys exist with sufficient permissions, API-based administrative access to FusionAuth will become unavailable. If your system relies on this API key for integrations or automation, those requests will fail.

To avoid disruptions, ensure that you have another valid API key with the necessary permissions before deleting the initial one.

Yes, it is possible to configure a custom domain for your SAML audience URL using FusionAuth's Custom Domain feature. This setup allows you to map your desired domain, e.g., https://auth.company.com, to your FusionAuth instance, enabling the SAML audience URL to use your custom domain.

Steps to Achieve This:

Set Up a Custom Domain: Configure a custom domain in FusionAuth (available for production deployments). Once the custom domain is set up, the SAML audience URL will change to reflect your domain, e.g., https://auth.company.com/samlv2/sp/<id>. Update DNS Records: Point the custom domain (auth.company.com) to FusionAuth Cloud using the provided instructions during setup. Verify SAML Configuration: Ensure the custom domain is reflected in the audience URL and SAML metadata. Update your SAML federation partners with the new audience URL.

Additional Notes:

Issuer Setting: The "Issuer" setting on the tenant configuration only affects JWTs and is unrelated to SAML audience URLs. Custom URL Limitation: You’re correct that the login.fusionauth.io option allows for aliases to the default company.fusionauth.io domain but does not impact SAML audience URLs. Setting up a full custom domain resolves this limitation.

Yes, it is possible to configure an Application with the SAML IdP feature enabled and use it as an IdP for another Application within the same Tenant.

The error you’re encountering indicates that FusionAuth cannot find an Application configured as a SAML IdP with the Issuer URL https://company-stage.fusionauth.io/samlv2/sp/af59262c-79ba-48c6-a0a2-4ab1d2fc15d3. This URL corresponds to the Identity Provider you configured in Settings > Identity Provider.

Resolution:

To fix this issue, update the SAML configuration for Application B as follows:

Navigate to Application B > Edit > SAML. Add the Issuer URL (https://company-stage.fusionauth.io/samlv2/sp/af59262c-79ba-48c6-a0a2-4ab1d2fc15d3) in the Issuer field.

By doing this, FusionAuth will recognize the SAML request and correctly map it to Application B.

The behavior you are experiencing is working as designed.

Currently, only the global_admin role can bypass the OTP requirement to disable 2FA. While the user_support_manager role allows managing other user account aspects, it does not have the necessary permissions to bypass 2FA for removal.

Feature Request Option:
If this functionality is critical for your workflow, you could consider submitting a feature request to extend this capability to additional roles in a future release. Or review this issue and comment if it meets your needs.

MAU Billing in Non-Production Environments:
Authentication activity in your non-production environments will not count toward your MAU billing as long as you are not using the "production" license key on those instances. How to Ensure Testing Does Not Impact MAU Totals: Use separate non-production license keys for your testing environments. Ensure these keys are applied to your non-production instances, isolating them from your production MAU calculations.

For more information, refer to the following resources:

FusionAuth Licensing Documentation What Makes a User Active?

This setup allows you to run comprehensive automated tests in your non-production environments without affecting your billing.

Bulk Registration of Existing Users:
FusionAuth does not currently provide a bulk endpoint for creating user registrations. However, you can achieve this by using the Create User Registration API to programmatically register users to app2. This requires iterating through the list of existing users and making an API call for each user to add the new registration. Best Practices for Future Scenarios:
To avoid manual one-time activities like this in the future, consider the following approaches: Enable Self-Service Registration:
If you are using FusionAuth's hosted login pages for user sign-ins, you can enable self-service registration for app2. With this feature, a user will automatically have a registration created for app2 when they attempt to log in for the first time. Programmatic Registration:
Implement a workflow in your onboarding process that ensures users are automatically registered to all relevant applications when they are created or updated in your system. Custom Scripts for Batch Processing:
Write a script to fetch all existing users and register them to any new applications as needed. This can be reused whenever new applications are added to your system.

References:

Create User Registration API Self-Service Registration

These steps should help streamline your workflow and reduce manual intervention for future scenarios.