Is it possible to set all users to have the passwordChangeRequired status set to true by default, so they are forced to reset their password upon their first login? Additionally, can we set a default password format as company{username}? For example, a user with the username 1234 would have the default password company1234.

Our FusionAuth instance only lists 11 Lambdas by default, and JWT Populate is not one of them. How can we create a JWT Populate Lambda?

Does FusionAuth provide an API to import roles for an application?

We are using the /api/user/forgot-password API for password resets, with sendForgotPasswordEmail set to false since we send our own email. However, users are now receiving two emails: our custom email and a password reset email from FusionAuth using our template. This issue occurs only in our pre-live and production environments, not in the local Dockerized version. What could be causing this?

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:

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

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

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

We found that a single user can have multiple active sessions simultaneously, meaning a user can log in multiple times. Is there a configuration in FusionAuth to restrict users to a single active session?

To handle nested routes and query parameters in this scenario, the solution typically involves using the redirect_uri and state parameters as part of the authentication request. These parameters allow Salesforce to pass the user's intended destination to FusionAuth, so the user can be redirected back to the correct route after login.

Implementation Steps:

1. Configure the Redirect URI:
   Salesforce should include the destination route (including any query parameters) in the state parameter of the authentication request sent to FusionAuth. This ensures that the user's original route is preserved during the login process.
2. State Parameter Usage:
   The state parameter can store the desired nested path and query parameters. Once FusionAuth completes the authentication, it will pass this state parameter back to Salesforce, which can use it to redirect the user to the correct location.
   Example:
   • User tries to access https://myapp.my.salesforce.com/customers/services/somenestedpath?someSearchArg=value.
   • Salesforce sends the following request to FusionAuth:
     https://your-fusionauth-domain/oauth2/authorize?client_id=yourClientId&response_type=code&
     redirect_uri=https://myapp.my.salesforce.com/services/auth/test/FusionAuth&state=/customers/services/somenestedpath?someSearchArg=value
   • After login, FusionAuth redirects back to Salesforce with the state parameter, allowing Salesforce to guide the user to their intended destination.
3. Limitations:
   • Check Salesforce’s documentation to confirm if it supports appending custom state or deep-linking query parameters for redirection.
   • If Salesforce does not support this behavior, it may be a limitation of the platform or the integration.

Next Steps:
Review Salesforce's documentation or consult their support to verify how to include deep-linking information in authentication requests. FusionAuth’s integration supports the state parameter for scenarios like this, but Salesforce must support passing and utilizing this information as part of the redirect process.

We have an integration between FusionAuth and Salesforce following the guide: FusionAuth-Salesforce Integration.

Typically, users access Salesforce via the link https://myapp.my.salesforce.com/customers/services/auth/sso/FusionAuth, which redirects them to the FusionAuth login page.

However, we’re encountering an issue where users cannot navigate to nested routes inside Salesforce. For example:

• A user trying to access https://myapp.my.salesforce.com/customers/services/somenestedpath?someSearchArg=value is not redirected to the FusionAuth login page when they are not logged in.

We need a solution where:

1. Users trying to access any route (including nested routes and query parameters) are redirected to the FusionAuth login page if not logged in.
2. After successful login, users are redirected back to the exact route they were attempting to access.

You can submit feature requests on FusionAuth’s public GitHub repository. Here’s the link: Submit a Feature Request.

Tips for Submission:

• Be as detailed as possible when describing your request.
• Include how the feature would work, its intended functionality, and the overall goal or problem it addresses.
• Providing use cases and examples can help prioritize the request.

We have a feature request idea: allow a tenant or application to ignore required MFA for users who log in via SSO. What is the best way to submit this request?

FusionAuth does not currently provide out-of-the-box support for security questions.

If security questions are critical to your solution, you would need to implement this functionality externally and integrate it with FusionAuth using API calls. For example:

• Authoring Security Questions: Create a custom interface for users to set up their security questions and store these securely in your system.
• Using Security Questions During Registration: Extend your registration workflow to include security questions, then associate the responses with the user data stored in your database.
• Using Security Questions During Credential Recovery: Implement a custom flow to verify the user's identity using security questions before proceeding with a password reset, and use FusionAuth’s APIs to handle credential recovery.

By building this functionality externally and integrating it via FusionAuth’s APIs, you can achieve the desired security question workflow while maintaining compatibility with FusionAuth.

How can we integrate security questions into FusionAuth? Specifically:
a) Authoring security questions.
b) Using security questions during the registration workflow.
c) Using security questions during credential recovery.

FusionAuth provides replay-resistant authentication mechanisms by adhering to industry standards for the technologies it implements. The level of replay resistance depends on the authentication workflow and specific standards followed.

Key Standards:

1. OAuth 2.0:
   • FusionAuth adheres to RFC 6749, RFC 8628, and OpenID Connect Core, which include mechanisms to mitigate replay attacks (e.g., nonce and state parameters).
   • Documentation: OAuth 2.0 Authorization Code Grant Example
2. Other Standards:
   FusionAuth follows established standards for other authentication protocols, such as:
   • WebAuthn: Provides strong, cryptographic-based authentication resistant to replay attacks.
   • SAMLv2: Uses unique assertions and timestamps to prevent replay.
   • OIDC (OpenID Connect): Includes nonce and other mechanisms to mitigate replay.

Replay Resistance Considerations:

• Replay resistance is primarily ensured when these protocols are implemented as defined by their standards. FusionAuth provides the tools and configurations necessary to follow these standards.
• However, deviations from these standards or implementation flaws outside of FusionAuth’s control (e.g., improper handling of state or nonce values) could introduce vulnerabilities.

I’m documenting our FusionAuth system login functionality and would like to know whether FusionAuth’s authentication is replay-resistant.

To clarify, a replay attack occurs when information transmitted between two parties is captured, stored, or altered, and then “replayed” later to disrupt communication or gain unauthorized access. Replay-resistant authentication ensures that captured data cannot be reused to impersonate a user or process.

Can you confirm if FusionAuth’s authentication mechanisms are replay-resistant? Please provide relevant documentation as well.