FusionAuth does not have a cascading Identity Provider (IdP) feature like Keycloak. Once an IdP is enabled for a FusionAuth application, it is available to all users logging into that application, and all enabled IdPs appear on the application’s login page, unless you modify the theme to change default behavior.

However, FusionAuth offers a feature somewhat similar to cascading IdPs: Managed Domains for Identity Providers. Here’s how it works:

On the login page, users are initially prompted to enter their email address. Based on the email domain, FusionAuth automatically redirects the user to a specific IdP or to the standard username/password login. For example, users with @company.com could be directed to a corporate SAML IdP for authentication, while other domains can be mapped to different IdPs or the default login flow.

Key Differences:

Predefined associations: You must configure email domains to map to specific IdPs beforehand. No chaining logic: FusionAuth does not attempt multiple IdPs sequentially during a single login attempt.

While Managed Domains is not equivalent to cascading IdPs, it is the closest feature FusionAuth provides for streamlining authentication based on user characteristics.

You can retrieve this data using FusionAuth's API, which provides specific endpoints for users, entities, and entity grants. The users object includes a registrations section that lists the applications each user is registered with. Here are the relevant API endpoints and documentation:

Users: Search for Users Entities: Search for Entities Entity Grants: Search for Grants

Steps to Retrieve Data:

To fetch all users, entities, or grants, perform a search query with a queryString parameter set to *. Use pagination as described in the API documentation to handle large datasets efficiently.

This approach allows you to systematically acquire the information your data engineers need on a daily basis.

The POST /api/user/change-password endpoint does not support a flag to require a password reset. However, you can achieve this by using the PATCH /api/user/{userId} endpoint and setting the passwordChangeRequired field in the request body.

Here’s an example JSON for the PATCH /api/user/{userId} call:

{ "user": { "passwordChangeRequired": true } }

Alternatively, you can set this requirement manually via the FusionAuth Admin UI:

Navigate to Users > Manage User > Edit User Dropdown. Select Require Password Change.

Documentation for reference:

Update a User

This ensures the user will be prompted to reset their password upon their next login.

Unfortunately, FusionAuth does not currently support using AWS IAM authentication for database connections or automatic rotation of database credentials. There is an open issue tracking this feature request:
GitHub Issue #973.

For now, this functionality would need to be handled outside of FusionAuth. For example, an external process or tool could be used to manage the generation and rotation of AWS IAM tokens. This might involve periodically restarting FusionAuth on a rolling 10-minute basis to ensure it picks up the updated credentials, or implementing a custom solution that works in conjunction with FusionAuth to manage database authentication. However, such approaches would not be officially supported by FusionAuth.

There seems to be a misunderstanding regarding the deprecation timeline. The /api/user endpoint itself is not being deprecated at the end of the year; only JWT authentication for that API is being deprecated. You can continue to use the /api/user endpoint by switching to API key-based authentication.

Steps to Continue Using /api/user:

Update your integration to authenticate API calls with an API key instead of JWT. Access data.salutation as usual through the /api/user endpoint. This data is part of the user.data object, which is populated by your integration and not automatically generated by FusionAuth.

Steps to Use /oauth2/userinfo:

Write and install a UserInfo lambda which can read the user.data object and augment the userinfo response to include the data.salutation value. Docs on this lambda.

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.

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.

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.

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 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, 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?

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

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.

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 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.

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 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.

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.