Currently, FusionAuth does not have native support for limiting users to a single session. However, this can be achieved programmatically using API calls.

Steps to Restrict to a Single Active Session:

User Logs In:
Upon a successful login, you will receive a new JWT for the session.

Retrieve Existing JWTs:
Use the GET /api/jwt/refresh endpoint to fetch all active JWTs for the user:

GET /api/jwt/refresh?userId={userId} Documentation: Retrieve JWTs

Revoke Other Sessions:
Loop through the retrieved JWTs and revoke all tokens except for the one associated with the most recent login. Use the DELETE /api/jwt/refresh endpoint to revoke each token:

DELETE /api/jwt/refresh?token={token} Documentation: Revoke JWT

Considerations:

This approach assumes the most recent login session is the one you want to keep active. It requires handling session management programmatically on your end.

Feature Request:

There is an open request for native session-limiting functionality in FusionAuth. If this feature is important to your use case, you can upvote the request on GitHub:
GitHub Issue #1363

Managed Domains Configuration:
If the client’s users share a common email domain (e.g., @example.com), you can use Managed Domains to streamline their login process. Here’s how it works: On the login page, users are first prompted to enter their email address. If the email domain matches a Managed Domain defined in the Identity Provider settings, the user is automatically redirected to Azure for authentication. If the email domain does not match, the user proceeds to the standard email/password login flow. For example, you could configure it so that users with @company.com emails are redirected to a corporate SAML Identity Provider, while your Azure users are handled similarly.
This approach changes the login page for all users by requiring them to enter their email first. For more details, refer to the Managed Domains documentation. IdP Hint with a Custom URL:
Another option is to use an Identity Provider (IdP) hint to create a unique login URL specifically for this client. Users accessing this custom URL are redirected directly to the Azure login page, bypassing the normal login flow. If the client uses the standard login link, they will still see the regular login page. This method ensures a tailored experience for the client without affecting other users. More details can be found in the IdP hints documentation.

Both approaches are effective, and the choice depends on your use case. Managed Domains is ideal for a seamless experience across shared email domains, while the custom URL approach offers greater separation for specific clients.

There are a few approaches and tools you can consider to streamline this migration process:

Database Migration Tools:
Tools like pgloader can help automate the migration of your MySQL database to PostgreSQL. Be aware that direct database migration carries risks. Corrupt or incomplete data may not surface immediately, and issues could arise months later. To mitigate this, test the migration extensively and consider working with third-party experts if needed. API-Driven Migration:
While using API calls for migration can be time-consuming, it ensures the data integrity FusionAuth requires. Automating this process with scripts and batching requests may help speed up the operation. Terraform for Configuration Migration:
Terraform can simplify the configuration migration process by treating your infrastructure as code. This approach allows you to standardize and automate the setup of configurations in your new FusionAuth Cloud environment. It’s especially useful for managing tenants, applications, and other configurations consistently.

Important Note:
If you choose to use a database migration tool, proceed with caution:

Verify the migrated data thoroughly to ensure it matches FusionAuth’s schema and expectations. FusionAuth cannot provide support for issues caused by manual database manipulation or corruption.

Combining API-driven data migration for sensitive information with Terraform for configuration and a reliable database migration tool can significantly reduce the time and effort required for this migration.

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.