Your understanding is correct: in FusionAuth, a user account must have a password to exist, and the platform requires a password when creating a user. This means there’s currently no way to completely eliminate the password field from a registration form using Custom Registration Forms, nor is there a supported method to bypass the password requirement entirely.

However, there’s a workaround if you’d like to simulate a passwordless experience. Using the Advanced Theme Editor, you can hide and automatically populate the password field on the registration page via JavaScript. This way, users won’t see or interact with the password field, but FusionAuth still receives a valid (though randomly generated) password value behind the scenes. To users, the experience feels passwordless, even though a hidden dummy password exists for each account.

More details about customizing the registration page can be found here:
Advanced Theme Editor Documentation

Yes, FusionAuth offers a feature called Managed Domains that can help implement this type of flow. When you set up Managed Domains under an Identity Provider and enable it for your application, the hosted login page will initially display only an email input field. Based on the user’s email domain, FusionAuth will then either redirect them to the appropriate Identity Provider (such as for employee logins) or continue to the standard username/password login for other users.

You can read more about Managed Domains here:
Managed Domains Documentation

Yes, you can disable the Facebook login and signup button through the FusionAuth dashboard. Navigate to Settings > Identity Providers, then edit the Facebook Identity Provider. At the top of the configuration page, you’ll find an “Enabled” toggle that lets you disable Facebook login globally for all applications. Alternatively, you can disable Facebook login for specific applications by using the application-level toggles at the bottom of the same page.

Yes, FusionAuth supports sending bulk emails to users. You can use the Send Email API to send messages to multiple users using a predefined email template. This allows you to communicate updates, such as changes to your IdP, to your entire user base.

For details on how to implement this, see the documentation here:
Send an Email API

There isn’t a way to stop FusionAuth from synchronizing the user object when using a generic connector. Even when a third-party system is the “system of record,” FusionAuth still requires a local user record to support its internal workflows and features. If you choose not to migrate users into FusionAuth, your external system must also provide application registrations on the returned user object to ensure proper integration.

Regarding your first question, there’s no way to prevent an error if the user.id changes between logins. The id field in the user object should remain consistent across logins. Changing it will inherently cause issues with how FusionAuth matches and manages user records.

For more detail, see the documentation here:
Using the Generic Connector as the System of Record

At this time, the generic connector in FusionAuth only supports a single error response type:

The connector returns a 404 Not Found in any failure scenario, whether: The user does not exist in the external system, or The user exists but provides invalid credentials.

This design is intentional and exists to prevent user enumeration attacks by not revealing which part of the login process failed.

Because of this security restriction:

You cannot display different error messages on the hosted login page for different connector failure scenarios. There’s no way to pass additional custom data or error context from the generic connector to the hosted templates for display purposes.

You can read more details here:
Generic Connector - Response

No, these exceptions are typically innocuous and indicate that the client closed the connection before FusionAuth could complete writing a response. For example, this can happen when a user navigates away while a page is still loading.

This is a known issue with Twilio’s SMS service. A good approach is to use a dedicated Twilio phone number only for MFA codes, and another number for other notifications so users are less likely to reply with “STOP.” Alternatively, you could switch to other MFA methods like TOTP, using apps such as Google Authenticator or Authy, or use email-based MFA. Keep in mind that once a user sends “STOP,” Twilio blocks all future messages until they opt back in by texting “START.” Educating users not to reply “STOP” to MFA messages is also helpful.

This issue may occur if the Forgot Password email template is still enabled in FusionAuth. To resolve this:

Disable the Forgot Password email template at the tenant level:
Navigate to Tenant > Edit Tenant > Email tab > Template Settings.
Set the Forgot Password template to Feature Disabled.

Check the application-specific settings:
If you have an application-specific template set up, ensure the Forgot Password template is also disabled under the Application settings.

Verify API configuration in the PHP client (if applicable):
If you’re using the PHP client, ensure sendForgotPasswordEmail is explicitly set to "false" (as a string with quotes), not just false (boolean). This ensures the value is passed correctly.
These steps should prevent FusionAuth from sending its own Forgot Password email when the API is called, resolving the double-email issue.

FusionAuth does not currently offer an API specifically for importing roles in bulk. However, roles can be created for an application using the following approaches:

Create a Single Role via API:
Use the POST /api/application/{applicationId}/role endpoint to create roles individually.
Documentation: Create an Application Role Create Multiple Roles During Application Creation:
When creating an application via the POST /api/application endpoint, you can define multiple roles as part of the application configuration. This is the most efficient way to set up multiple roles at once if you are creating a new application.

While there isn’t a dedicated role import API, combining these endpoints allows flexibility in managing roles programmatically.

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.