Yes, this can be achieved using the FusionAuth API. Here's how you can implement it:

Set the default password for each user:
Use the POST /api/user/change-password endpoint to set the user's password to the desired format, e.g., company1234. Refer to the "Change a User's Password using an email address or username" section of the FusionAuth documentation. This allows you to update a user's password in a single API call without requiring the Forgot Password flow. Require the user to change their password:
Use the PATCH /api/user/{userId} endpoint to set the passwordChangeRequired field to true. This ensures that the user will be prompted to change their password upon their next login.

API Documentation for reference:

Change a User’s Password Update a User

Optional Customization:
To guide users on the login page to use the default password format, you can customize the messaging through FusionAuth Themes:

Navigate to Simple Theme > Messages > Default. Add a custom message, such as password=Password is company+username, to inform users of the default password structure.

Here’s how you can approach securing access to your FusionAuth instance:

IP Access Control Lists (ACL):
You can define IP Access Control Lists in FusionAuth by navigating to Settings > IP Access Control in the Admin UI. Click the + icon to create a new ACL list. Add entries for each IP address or range you want to allow or block. Assign these ACLs to specific tenants or API keys as needed. Important Note:
IP ACLs restrict access to endpoints like /oauth2/, /account/, /email/, /password/, /registration/, and other user-accessible pages. However, they do not restrict access to the FusionAuth Admin UI unless the Admin UI is accessed via SSO.
Documentation: IP ACL API Overview Secure the Admin UI:
Since IP ACLs do not directly secure the Admin UI, consider the following options: Use a Trusted Proxy:
Place a trusted proxy at the edge of your network to filter incoming traffic before it reaches FusionAuth. The proxy can enforce IP-based restrictions or other security rules. In FusionAuth, configure your proxy under System > Networking, where you can specify the proxy’s IP address. If a request doesn’t go through the trusted proxy, FusionAuth will deny access.
Documentation: FusionAuth Networking Login Lambda for Additional Validation:
Implement a Login Lambda to validate login attempts further. This Lambda allows you to execute custom code during login, such as checking the origin IP or other request details to block unauthorized attempts.
Documentation: Login Lambdas Recommended Next Steps: Configure IP ACLs for your tenants and API keys to secure application-level access. Implement a trusted proxy to filter admin panel access based on source IP. Use a Login Lambda for additional request-level security, if needed.

By combining these approaches, you can enhance the security of your FusionAuth deployment and mitigate unauthorized access.

The 11 Lambdas you see are the default ones included with FusionAuth. To create a JWT Populate Lambda, follow these steps:

Navigate to Settings > Lambda in the FusionAuth Admin UI. Click the green + button in the top right to create a new Lambda. In the "Type" dropdown, select JWT Populate. Configure your Lambda logic as needed.

For additional guidance, you can refer to the JWT Populate Lambda documentation, which includes a helpful video walkthrough of the process.

To update or extend a user’s account expiry date, you can use the FusionAuth User API to modify the expiry field. You can either set a new expiration date or set the field to null to remove the expiry entirely.

Here’s an example of a PATCH request to update this field:

curl --request PATCH \ --url https://local.fusionauth.io/api/user/42661043-9ab8-4bb8-8778-85217aa05086 \ --header 'Authorization: TulwCDDOmOtvXAVTsRUI4LfSWlF-Bd78uTnQhgviMQG9a1a3Qn7emwBn' \ --header 'Content-Type: application/json' \ --header 'X-FusionAuth-TenantId: 30665132-6767-6665-3132-323466613934' \ --data '{ "user": { "expiry": null } }'

Explanation:
Replace the URL, user ID, and tenant ID with your instance's values.
Setting "expiry": null removes the expiration date and reactivates the user account.
This should resolve the issue and allow the user to log in again.

Monthly Active Users (MAU):
Using the Bulk User Import API will not count against your monthly active users (MAU) quota. This makes it suitable for staging or non-production environments where users are frequently added and removed. User Deletion Performance:
The Bulk Delete API processes users one by one, performing verification checks for each user, which can cause delays. Unfortunately, there is currently no faster or more efficient way to delete users in bulk due to the way the API is designed. Alternative Approach:
While tools like Terraform can automate the process of importing and deleting users, this essentially scripts the same API calls and will still encounter the same deletion delays. However, Terraform may simplify managing the environment by automating repetitive tasks. Documentation: FusionAuth Terraform Integration

If the deletion delays significantly impact your workflow, consider submitting a feature request to FusionAuth for performance improvements in bulk deletion.

Yes, this can be achieved using FusionAuth’s Webhooks. You can trigger a Webhook when the user.registration.verified event occurs and send the necessary data to Google Tag Manager (GTM).

Steps to Set Up:

Create a Webhook in FusionAuth: Navigate to Settings > Webhooks in the FusionAuth Admin UI. Create a new Webhook and configure it to trigger on the user.registration.verified event. Enable the Webhook for Your Tenant: Go to Tenant > Webhooks and enable the Webhook for the desired tenant. Integrate with GTM: While FusionAuth Webhooks send data to external systems, ensure that GTM can ingest Webhook data. From my research, GTM supports Webhook ingestion, but you may need to configure a custom setup within GTM to process the incoming data.

Resources for Reference:

FusionAuth Events and Webhooks User Registration Verified Event

This approach allows you to track account verification events seamlessly.

Unfortunately, the Entity Grants API only supports POST as an upsert operation, meaning you must provide the entire list of permissions with each request. It does not currently allow selective addition or removal of permissions.

If this feature is important to your workflow, we recommend submitting a feature request on FusionAuth's GitHub repository. Feature requests are prioritized based on community upvotes.

Resources:

Entity Grants API Documentation Submit a GitHub Issue

Different Signing Keys for ID and Access Tokens:
Configuring different signing keys for ID tokens and access tokens is an edge case, typically used when specific requirements exist: Use Case: Access tokens may need to be signed with HMAC for speed, particularly if they are consumed by resource servers within a controlled environment. ID tokens might require RSA signing to ensure security since they are often handled by clients that cannot be fully trusted. Rotating keys independently for ID and access tokens might be necessary to meet compliance or security policies. Best Practice:
Unless you have a clear requirement for different key configurations, it's generally unnecessary to use separate keys. A unified approach simplifies key management and reduces potential issues. Shadow Keys (client_secret as Signing Key):
Shadow keys are primarily included to ensure compliance with OpenID Connect (OIDC) specifications. Use Case: The client_secret as a signing key is used for ID tokens to meet OIDC compliance requirements. However, it’s not allowed for access tokens since access tokens are designed to be more flexible and are often consumed outside of the client-server context. Best Practice:
This feature is useful only for OIDC-compliant setups where such signing methods are mandated. If OIDC compliance is not a requirement, shadow keys and their configurations are likely unnecessary.

Summary:
Both features—different signing keys and shadow keys—are provided to accommodate specific compliance or architectural requirements. For most use cases, these options are not needed unless dictated by your organization's security policies or external compliance requirements.

Providing Empty Strings for Text Templates:
While it is technically possible to provide empty strings for the text version of the templates, this is not recommended. FusionAuth sends both the text and HTML versions of the email, with each MIME encoded. The email client decides which version to render. If a user’s email client renders the text version, the email will appear blank if the text template is empty.
Recommendation:
Create a simple text version of the email by stripping out the HTML formatting (e.g., removing <p></p>, <a></a>, etc.). You can refer to FusionAuth's default email templates for examples of how to format text-only emails. Criteria for Sending Text vs. HTML Emails:
The choice of rendering text or HTML emails is determined by the recipient's email client. Most modern email clients prioritize HTML, but some may fall back to text if they do not support HTML or if the user has configured their preferences for plain text emails. Forcing HTML Emails:
FusionAuth does not provide a way to force emails to always render in HTML, as the decision ultimately lies with the recipient’s email client. However, providing well-constructed HTML templates ensures that most users will receive the intended design, as HTML rendering is the default behavior for the majority of email clients.

By creating both text and HTML versions of your templates, you ensure compatibility with all email clients while maintaining your preferred HTML formatting for most users.

To achieve this behavior, you can use IdP Hints. IdP Hints allow you to send the user directly to a specific Identity Provider (e.g., Google or Facebook) without stopping at the FusionAuth Hosted Login Page. This approach aligns with the flow you described, bypassing the hosted page entirely.

Steps to Use IdP Hints:

Append the appropriate IdP hint parameter to the /oauth2/authorize request URL. The hint will direct FusionAuth to initiate authentication with the specified IdP immediately, skipping the hosted login page.

Documentation Reference:

FusionAuth Identity Provider Hints

By using IdP Hints, you can streamline the login process and eliminate the need for JavaScript-based workarounds on the hosted login page.

The sendSetPasswordEmail functionality currently has a limitation in that it doesn’t allow you to pass custom data for use in the email template through the API. However, you can still achieve personalization by configuring the email template directly in the FusionAuth Admin UI.

Steps to Personalize the Setup Password Email:

Edit the Email Template: Navigate to Customizations > Email Templates > Setup Password in the Admin UI. You can either edit the existing default template or duplicate it to create a new one. Use variables like ${user.firstName!'Unknown User'} or any other user data fields to customize the message. Assign the Template to Your Application: Go to Applications in FusionAuth. Edit your application and assign the appropriate template to the Setup Password field. Consider Custom Message Content: Include static or semi-dynamic content like "You were invited by ABC" in the email template. If you have multiple initiators, you might need to create separate templates for each scenario.

Documentation for Reference:

Email Templates and Replacement Variables FusionAuth Email Templates

While the API does not allow for passing custom fields directly for sendSetPasswordEmail, configuring the templates in the Admin UI should allow you to achieve the desired level of personalization.

Unfortunately, FusionAuth does not support changing a user’s ID after the user has been created.

However, when creating users via API, you can specify a custom user ID at the time of creation. This allows you to control user IDs during the initial setup.

API Reference:

Create a User API

Since the IDs are already assigned, your best option might be to adjust your integration logic or recreate the users with the desired IDs.

FusionAuth's TOTP implementation is compatible with most popular authenticator apps that follow the industry-standard TOTP algorithm, specifically those using HMACSHA1. While we cannot provide an exhaustive list, here are some commonly used authenticator apps that are known to work with FusionAuth:

Google Authenticator Authy Microsoft Authenticator LastPass Authenticator 1Password

Compatibility Check:

If an authenticator app does not support FusionAuth’s TOTP, it will simply fail to recognize the QR code when scanned.

Documentation Reference:

For more details about FusionAuth's TOTP implementation and requirements, refer to the FusionAuth TOTP Documentation.

Most users should have no issues using any modern TOTP-based authenticator app.

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:

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

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.

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.

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:

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

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.