Posts made by FASupportBot

FASupportBot

The Helm chart for FusionAuth 1.53.4 has been released and should now be available in the FusionAuth charts repository.

In the meantime, if you need to deploy a specific FusionAuth version before the corresponding Helm chart is released, you can override the image tag in your Helm values file:

image:
  tag: "1.53.4"

This allows you to use the latest Helm chart while specifying the exact FusionAuth Docker image version you need.

Rate Limit Configuration

FusionAuth does not publish rate limits publicly and they are subject to change.

Please open a support ticket to obtain more guidance.

Whitelisting for Performance Testing

Since these are network-level rate limits, they cannot be configured within your deployment. However, IP allow listing is available to bypass rate limiting for performance testing if your IP address meets these requirements:

It is static
It is owned by your company (not shared infrastructure like a CDN)
It is associated with a production server (not a developer's laptop)

If you can provide a static IP address that meets these criteria, you can open a support ticket to get it allow listed. Note that allow list changes typically take two to three business days to implement.

Best Practices for Performance Testing

When planning load or performance tests against FusionAuth Cloud:

Open a support ticket before testing to notify the FusionAuth team of your planned stress test window
Don't use Basic cloud deployments for performance testing, as they run on limited infrastructure and results won't be representative. Use a Business or High-Availability plan instead, which you can spin up, test, and tear down as needed
Implement exponential backoff when you receive a 429 response - this is the recommended approach for handling rate limits gracefully
Distribute requests over time rather than sending bursts of traffic

Alternative Testing Approaches

If you cannot obtain an allow-listable static IP address (such as for developer machines or CI/CD pipelines), consider:

Running a self-hosted FusionAuth instance for automated testing, which gives you full control over rate limiting configuration
Using smaller-scale testing that stays under the rate limits

About Risk Signals and Email Volume

If you're seeing a significant increase in suspicious login emails after upgrading to 1.68.0 or later, this is because FusionAuth introduced comprehensive Risk Signals in version 1.68.0. Previously, only Impossible Travel was tracked. Now additional signals are evaluated including:

Untrusted Device
Unrecognized Device
Recent Password Change
Recent Identity Change
Dormant Password
Suspicious Agent

All Risk Signals are enabled by default without any configuration changes.

Managing Email Volume

You can tune which Risk Signals trigger suspicious login alerts:

Go to Tenants → Select tenant → Edit → Security tab → Client Risk Configuration
Disable specific Risk Signals that are generating too many false positives for your use case

Monitoring Without Sending Emails

You can monitor webhook events while tuning your Risk Signals without sending emails to users:

Go to your tenant/application settings → Identities tab
Change the Suspicious Login template to "No Template Selected"
Monitor your webhook endpoint to see which Risk Signals are triggering
Fine-tune your Risk Signal configuration
Re-enable the email template once you're satisfied with the detection accuracy

The webhook fires whenever a Risk Signal threshold is met, independent of whether an email template is configured. This allows you to observe and tune the system before alerting end users.

FASupportBot

After upgrading FusionAuth, we're seeing suspicious login emails being sent to end users, but we're not receiving user.login.suspicious webhook events in our webhook logs. We've confirmed:

The webhook has user.login.suspicious set to true in eventsEnabled
The webhook is scoped to the specific tenant where logins are occurring
Other webhook events (like user.action, user.password.reset.success, etc.) are working correctly
Reactor license is activated
Users are definitely receiving suspicious login emails, confirming the events are being triggered

Our webhook configuration shows:

{
  "eventsEnabled": {
    "user.login.suspicious": true,
    // ... other events
  },
  "tenantIds": ["<your-tenant-id>"],
  "global": false
}

What configuration might we be missing to receive these webhook events?

FASupportBot

Yes, you need to create two separate applications within the same tenant in FusionAuth. Here's how to configure this:

Configuration Steps

Create both applications in the same tenant - Users are scoped at the tenant level, so applications in the same tenant can share authentication state through FusionAuth's SSO session.
Enable self-service registration on the second application - This ensures a seamless login experience. When a user navigates to the second application while already authenticated to the first, they will be automatically registered and logged in.

How It Works

User logs into the first application at your registration URL to create their account. Make sure the rememberDevice parameter is true or checked. You can modify your theme to hardcode that value.
While that session is valid, they navigate to the second application's login URL
They are automatically registered and authenticated to the second application without manual intervention

The key to this working is that FusionAuth creates an SSO session at the tenant level when a user logs in and rememberDevice is checked. When the authenticated user tries to access the second application, FusionAuth recognizes the existing SSO session and automatically creates a registration for that user in the second application (when self-service registration is enabled).

Password Reset Behavior

Because users are scoped at the tenant level, a password reset applies to all applications under that tenant. Users can utilize the password reset page for the first application and will be able to log in at the second application with the new password.

Sharing Templates

Both applications can share the same theme and templates. Themes are assigned at the tenant level (though you can also assign application-specific themes if needed starting with FusionAuth 1.27+). This means you can configure one set of templates - including password reset, login, and user management pages - that will be used by both applications.

Pre-creating User Accounts

If you create user accounts ahead of time, you can automatically include the registration for the second application when creating the users. This would mean adding that application to their registrations when you create the account initially using the Create a User and Registration API.

Recommendations to minimize impact:

Serialize imports: Do not run multiple imports simultaneously. Even when migrating multiple clients, avoid having two clients in the initial import phase at the same time.
Pre-hash passwords: Since you're already sending passwords with hash, salt, factor, and encryption scheme, this will significantly reduce load during imports. If passwords were sent as plaintext, FusionAuth would need to hash each one on import (which can take several hundred milliseconds per user).
Start with smaller batches: Rather than immediately using 100k user batches, start smaller to monitor system performance during imports. If performance is acceptable, gradually increase the batch size until you find the right balance between performance and import speed.
Avoid transactional webhooks: You mentioned using Kafka integration instead of custom webhooks, which is good. Ensure you are only using the Kafka integration for events and not using any transactional webhooks, as these can add additional load during imports. Transactional webhooks block the operation until the webhook completes, which can significantly slow down bulk imports. Non-transactional events (like those sent to Kafka) are fire-and-forget and don't block the import process.
Limit concurrent operations: You mentioned planning to run only one import call at a time from one worker, which is the right approach. Updates using the PATCH endpoint can occur in parallel as they should be infrequent.
Monitor database performance: Keep an eye on your database connection pool and query performance during imports. The shared database is typically the bottleneck in multi-tenant scenarios under heavy load.

By following these practices, you can minimize the impact of bulk imports on other tenants in your multi-tenant FusionAuth deployment.

Option 1: Use a Reconcile Lambda (Recommended for Social Login)

For social login providers like Google, you can use a reconcile lambda to intentionally overwrite the user data with placeholder values before it's permanently stored:

function reconcile(user, registration, idToken) {
  // The idToken is the response from the tokeninfo endpoint
  // https://developers.google.com/identity/sign-in/web/backend-auth#calling-the-tokeninfo-endpoint
  
  user.firstName = "Purposely not set";
  user.lastName = "Purposely not set";
  user.fullName = "Purposely not set";
  user.imageUrl = "http://www.notset.com";
}

This ensures that personal data from the social provider is replaced immediately during the reconciliation process.

Option 2: Minimal Registration Form

For new user registrations (non-social), configure your registration form to collect only email and password, avoiding the collection of first/last name entirely.

Option 3: Use Webhooks to Clear Data

Implement a user.create.complete webhook that listens for new user creation events, then use the FusionAuth User API to clear the personal data fields and move them to your profile service. Note that this approach means user data will briefly exist in FusionAuth before being cleared.

Option 4: Lambda with External Fetch (Advanced)

You could use lambdas with fetch calls to move data to your profile service and set FusionAuth fields to null. However, this introduces latency due to network calls during authentication flows.

For Existing Users

If you already have users with stored data, use the User API to programmatically clear the values for all existing users.

user-data

When using FusionAuth's hosted login pages with social login (e.g., Google), personal information like first name, last name, and full name are automatically stored in the FusionAuth user object.

We want to store only the email address in FusionAuth and move all other personal information to our own profile service. What is the best approach to prevent or remove this data from FusionAuth while still using social login and registration?

Is there a way to prevent FusionAuth from storing this information in the first place, or do we need to clear it after user creation?

Posts made by FASupportBot

Related Documentation

Rate Limit Configuration

Whitelisting for Performance Testing

Best Practices for Performance Testing

Alternative Testing Approaches

Related Documentation

Related Documentation

About Risk Signals and Email Volume

Managing Email Volume

Monitoring Without Sending Emails

Configuration Steps

How It Works

Password Reset Behavior

Sharing Templates

Pre-creating User Accounts

Related Documentation

Recommendations to minimize impact:

Related Documentation

Option 1: Use a Reconcile Lambda (Recommended for Social Login)

Option 2: Minimal Registration Form

Option 3: Use Webhooks to Clear Data

Option 4: Lambda with External Fetch (Advanced)

For Existing Users