Hiya @florent-bossuyt ,

Thanks for using FusionAuth.

The upgrade to 1.59.0 added support for phone number as a first class identity. While I don't know for sure, it is possible that impacted lastLoginInstant. I'm not aware of any bug filed.

It's also possible you can find the data previously in the lastLoginInstant in the user.identities[x].lastLoginInstant value, available when you retrieve a user.

Since this is not a known issue, there's no documented procedure for reconciling the data, unfortunately.

Here's one approach, though.

If you have a database backup of the 1.57.0 release, you could stand up a FusionAuth instance pointing to that, and find all the users with a lastLoginInstant that is not null (set A). You'd then run the same query against your prod instance (set B). Then find the folks in set A who are not in set B (call them set C). Set C are the people you need to update.

Unfortunately, you can't update their lastLoginInstant directly. But you can fake a login using the passwordless APIs, which should set it. That is outlined here.

So you'd want to perform that for all the users in set C.

Hope that helps.

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.

Related Documentation Deploy with Kubernetes - Helm Chart Configuration - Complete guide on configuring and deploying FusionAuth using Helm charts Deploy FusionAuth to the Cluster - Instructions for installing and verifying your Helm deployment Kubernetes Overview - Overview of FusionAuth on Kubernetes with architecture diagrams Upgrade FusionAuth - General guidance on upgrading FusionAuth installations

When you override the image tag in your values.yaml file, you can verify the correct version is deployed by checking the IMAGES column in your Kubernetes deployment:

kubectl get deployments -o wide

The rate limiting you're encountering is applied at the WAF (Web Application Firewall) level on FusionAuth Cloud, not from the FusionAuth application itself. These rate limits protect customers and are standard across all FusionAuth Cloud deployments.

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 Related Documentation FusionAuth Cloud - CAPTCHA and Rate Limits FusionAuth Cloud - Load Testing Troubleshooting FusionAuth Cloud API Calls User Search API Documentation Advanced Threat Detection - Customizable Rate Limiting (for application-level rate limits within FusionAuth)

The postMethod variable can be null or missing in certain scenarios (such as when a verification link is clicked multiple times), causing the FreeMarker template to fail.

To fix this, you need to provide a safe fallback for the postMethod variable. Update line 16 in your registration/verify.ftl template from:

[#if verificationId?? && postMethod]

To:

[#if verificationId?? && (postMethod!false)]

The !false syntax provides a default value of false when postMethod is null or missing, preventing the FreeMarker exception.

Steps to apply the fix:

Navigate to Customizations → Themes in the FusionAuth admin UI Edit your theme Locate the registration/verify.ftl template Update the conditional check as shown above Save the theme

This pattern can be applied to other templates where variables might be null or missing in certain execution paths.

Why this happens:

According to the FusionAuth documentation, the postMethod variable is not a standard template-specific variable for the /registration/verify template. It is typically available on other verification templates like /email/verify (where it defaults to true). The registration verify template is rendered when a user clicks the URL from the verification email and the verificationId has expired or is invalid. In these scenarios, postMethod may not be set in the template context, which causes the FreeMarker error when attempting to evaluate it as a boolean.

Related Documentation Theme Template Variables - Verify Registration - Documents the variables available in the registration verify template Theme Template Variables - Email Verification - Shows that postMethod is documented for email verification but not registration verification Theme Template Variables - Complete reference for all template variables across different templates

This issue was caused by a bug that existed prior to version 1.68.0. In earlier versions, there was a problem where LDAP connectors scoped to specific domains could incorrectly be called (or not called) for users outside those domains. This could result in the connector appearing to stop functioning entirely after an upgrade.

Solution:

Recreate the LDAP connector configuration. When doing so, verify the Domains field:

If you need the connector to apply to all users, use a wildcard (*) for the domains. If you need domain-specific scoping, explicitly configure the same domains you had previously.

This bug was fixed in FusionAuth 1.68.0. See the release notes for details:

Fixed an issue where Connectors configured for a specific domain in a Tenant could be called for users outside of that domain.

If you encounter this issue after upgrading to 1.68.0 or later and recreating the connector does not resolve it, verify:

Debug mode is enabled for both the connector and the reconcile lambda. The LDAP server is reachable from the FusionAuth instance. Event log and system log (fusionauth-app.log) for any connection or authentication errors.

The user.login.suspicious webhook event requires the Client Risk Configuration to be enabled at the tenant level. Even though Risk Signals are evaluated by default, the webhook event itself won't fire unless this configuration is explicitly turned on.

To enable it:

Navigate to Tenants → Select your tenant → Edit → Security tab Find the Client Risk Configuration section Ensure it's enabled for your tenant

Additionally, verify that the user.login.suspicious event is enabled in the tenant's webhook settings:

Go to Tenants → Select your tenant → Edit → Webhooks tab Confirm user.login.suspicious is checked/enabled

Once both are configured, your webhook should start receiving user.login.suspicious events along with details about which Risk Signals triggered the suspicious login determination.

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.

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.

Related Documentation Implementing Single Sign-On - Complete guide to configuring SSO between applications Self-Service Registration - How automatic registration works when SSO is enabled Create a User Registration API - Programmatically register existing users to additional applications Application Themes - Configure application-specific themes if needed Themes Documentation - Customize and share login pages and templates across applications

FusionAuth tenants provide logical isolation, not physical isolation. While users, applications, groups, and configuration are logically separated per tenant, all tenants in an instance share the same FusionAuth nodes, database, and search index.

This means that while importing data into one tenant will not impact the data integrity in another tenant, it does draw on the same compute and database capacity that other tenants' logins and profile updates use. Large imports can potentially affect performance across all tenants.

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.

Related Documentation Multi-tenancy Guide - Overview of FusionAuth's multi-tenant architecture and concepts Levels of Isolation - Explanation of logical vs. physical isolation in FusionAuth Import Users API - API documentation for bulk user imports Password Hashes - Details on importing pre-hashed passwords to improve performance Transactional vs. Non-Transactional Events - Understanding event types and their performance impact Kafka Integration - Using Kafka for non-blocking event processing Scaling Your Auth - Best Practices - Performance and scaling considerations for authentication systems

At this time, FusionAuth Cloud does not support customizing HTTP security headers on individual tenant deployments. There is an existing GitHub feature request tracking this capability, but it is not currently on the roadmap and no ETA is available for when this might be added.

If you are running a self-hosted FusionAuth instance, you can configure these headers using a reverse proxy (nginx, Apache, etc.) in front of FusionAuth. For FusionAuth Cloud customers, this configuration is managed at the infrastructure level and cannot be modified per-tenant.

You may want to subscribe to or comment on the relevant GitHub issue to track progress on this feature request.

This is a known bug in FusionAuth 1.69.x that affects the System Logs page when viewing logs from multiple nodes in a cluster.

The issue has been confirmed and logged with the FusionAuth development team. The 401 errors occur when the UI attempts to fetch log content from other nodes in the cluster, causing the tab-switching functionality to fail intermittently.

Unfortunately, there is no workaround available at this time. The bug will be addressed in a future release.

As a temporary measure, you may need to:

Refresh the page multiple times when checking logs across nodes Navigate away from and back to the System Logs page to trigger a reload Access logs directly from individual nodes if you have that capability in your deployment

Once this issue is resolved in a future version, the System Logs page should reliably display logs from all nodes without authentication errors.

FusionAuth does not have a direct passthrough option to prevent storing user data from social login providers. However, there are several approaches to handle this:

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.

You can use the linked APIs, and that’s the option most people find first. The step-up flow in the API docs works, but means your app owns the challenge. It has to start it, collect the code, and handle the result. That’s a lot for what is basically “make the user log in again because they are about to do a sensitive thing.”

There’s another way that’s a little different, and it leverages login. Since version 1.60 the authorize endpoint supports the standard OIDC prompt and max_age parameters.

When your app hits a sensitive action, don't call any specific APIs. Instead, it can redirect the user to /oauth2/authorize with prompt=login and/or with a max_age small enough that their existing SSO session doesn’t satisfy it. FusionAuth shows the hosted login page, the user authenticates, and you get a fresh token back. Same code you already wrote for login, with one query parameter added.

Make sure you put the current page/location in the state so you can deliver the customer back to where they were. Here's a video on deep linking.

Using either max_age=0 and prompt=login end up in roughly the same place. I’d use max_age if you want a window like “re-auth if it’s been more than five minutes,” and prompt=login if you want it every time.

A successful redirect doesn’t prove everything. Your app still has to decide whether the token it’s looking at came from a recent authentication.

That’s what the auth_time claim is for. It’s a reserved claim in the JWT body (it moved there in 1.60, and lambdas can’t override it), so your resource server compares it against the clock and rejects beyond your threshold. If it’s too old, send the user back through authorize.

That’s basically the max_age half of RFC 9470, just without FusionAuth issuing the WWW-Authenticate challenge for you. You’d write that 401 yourself.

Caveats:.

This forces a re-login, not necessarily a stronger one. If the user re-authenticates with a password and nothing else, you’ve proven recency and nothing about strength. If you need the second factor on that re-auth, you need MFA to actually fire. A static policy of Required will do it. On Enterprise, the MFA Requirement Lambda can make the decision per request. There’s no acr-style “this was step-up” claim. You get “authenticated at time T,” not “authenticated with a second factor at time T.” If your auditors need the latter, this approach won’t give it to you cleanly, and falling back to the step-up auth API is a better option. It’s a full redirect. For a banking-style “confirm this transfer” flow where bouncing the user to another page is a non-starter, the step-up API approach is still right. This only works when you are using the hosted login pages, not the Login API.

The short version: if sensitive actions are coarse-grained (“view the billing page,” “change the email address”), the redirect approach might work for you. It’s less code, the hosted pages handle the UI, and you’re not maintaining a custom MFA challenge.

But if you need per-operation binding or proof of which factor was used, look at the step-up API.

This behavior occurs when the client sends an Accept-Encoding header that includes compression algorithms, but FusionAuth's response handling doesn't support the requested encoding method in certain configurations.

The solution is to explicitly use Accept-Encoding: identity in your API requests. The identity value indicates that no encoding transformation should be applied, which FusionAuth handles correctly.

If you're using an HTTP client library that automatically adds Accept-Encoding: gzip or similar headers, you should:

Override the default Accept-Encoding header to use identity Or configure your HTTP client to not send compression-related headers automatically

Example:

GET /api/user/search HTTP/1.1 Host: your-fusionauth-instance.com Authorization: <your-api-key> Accept-Encoding: identity

This ensures consistent API responses without encountering 406 errors related to content encoding negotiation.

@chatteberg I just saw your post. If you have a paid support plan you can open a ticket. If you do not have a paid support plan, are you still experiencing the issue?

You can avoid the fresh local install by pulling the theme files directly from the fusionauth-theme-history repository:

github.com/FusionAuth/fusionauth-theme-history/tree/main

To use this with the theme-helper repo:

Download your current customized theme using download.sh from the theme-helper repo Grab the new target version's theme files from fusionauth-theme-history Run diff-themes.sh from theme-helper against the two folders to see what changed

This approach lets you diff your customized theme against the base theme for any FusionAuth version without needing to spin up a local FusionAuth instance.

Alternative approaches:

If you prefer working directly with git, you can clone the theme-history repo and use git's built-in diffing. For example, to generate a patch between two versions:

git format-patch 1.61.0..1.64.1 --stdout > update-themes.patch

Then apply it to your theme repository:

git am --3way update-themes.patch

You can also use GitHub's built-in diff viewer to compare themes across versions directly in your browser.

Related Documentation Upgrade an Advanced Theme - Complete guide for upgrading custom themes Theme History Repository - Official documentation on using the fusionauth-theme-history repo (available back to version 1.23.0) Theme Helper - Documentation for the fusionauth-theme-helper tool Advanced Theme Upgrade Notes - Version-specific upgrade requirements and breaking changes Themes API - API reference for programmatically retrieving theme files

FusionAuth 1.69.0 introduced changes to how Apple identity provider keys are handled. If your Apple identity provider was configured before upgrading to 1.69.0, you may need to update the key configuration.

To resolve this issue:

Review the 1.69.0 migration guide for specific details about Apple identity provider key changes Navigate to your Apple identity provider configuration in the FusionAuth admin UI Verify that the signing key is properly configured and valid If needed, re-import or reconfigure the Apple private key used for the identity provider Test the Sign in with Apple flow after making these changes

The migration guide contains detailed steps for addressing key-related issues introduced in this version.

When submitting a custom password hasher plugin (or any plugin JAR) for installation on FusionAuth Cloud, you should:

Open a support ticket through the account portal as normal (text-only is fine) Reply to the ticket conversation in Slack with the plugin JAR file attached

The account portal does not accept file attachments during ticket creation, but replying via Slack to an open ticket thread allows you to send files directly to the support team.

Note: Some file-sharing platforms (like Slack) may block .jar files for security reasons. If this happens, you can zip the JAR file first and attach the .zip instead.

Installation considerations

When requesting plugin installation, be sure to specify:

Which specific Cloud deployments/tenants need the plugin installed Whether users are actively logging in (there may be 1-2 minutes of downtime during deployment) Your preferred time window for the installation if downtime is a concern Any considerations for dev/test environments if you have ongoing testing

The support team will handle uploading and rolling the deployment with the new plugin.

This MessagingException: Exception reading response error is often related to network issues or SMTP timeout configuration. Here's how to address it:

Check and Adjust SMTP Timeout Settings

The default SMTP timeout in FusionAuth is 2 seconds, which may be too short if your SMTP provider experiences occasional network slowness. You can increase the timeout by:

Navigate to Tenants > [Your Tenant] > Edit > Email > Advanced In the Additional properties field, add or adjust these configuration values: mail.smtp.timeout=5000 mail.smtp.connectiontimeout=5000

This increases the timeout to 5 seconds. Adjust the value as needed based on your SMTP provider's typical response times. The Additional properties field can contain any Java mail property, and these values will override FusionAuth's defaults.

Email Retry Policy

FusionAuth does not have a built-in retry mechanism for failed email sends. FusionAuth connects directly to your configured SMTP server at the tenant level without using a local mail queue. If an email fails to send due to a connection issue or timeout, FusionAuth will not automatically retry it.

Additional Troubleshooting Steps

Enable SMTP Debug Logging: In your tenant's Email settings, enable the Debug enabled option. This will provide detailed SMTP transaction logs in the FusionAuth event log, which can help identify the root cause of intermittent failures.

Review Event Logs: Check System > Event Log for error events. FusionAuth always creates an event log entry of type "Error" when it cannot send an email.

Send Test Emails: Use the Send test email button in Tenants > [Your Tenant] > Email to verify your SMTP configuration under different conditions.

Implementing Your Own Retry Logic

To handle retries, you can set up a webhook-based solution:

Configure a webhook for the event-log.create event Monitor events delivered to your webhook endpoint When you detect a MessagingException event, trigger an API call to the appropriate endpoint (e.g., /api/user/forgot-password for password reset emails) Important: Implement retry limits in your script to avoid infinite loops with invalid email addresses

This approach gives you full control over retry logic, backoff strategies, and error handling for failed email deliveries.

Related Documentation Configure SMTP - SMTP Settings - Complete SMTP configuration guide Tenants - SMTP Settings Form Fields - Details on the Additional properties field and how to customize Java mail properties Troubleshooting Email - Comprehensive email troubleshooting guide Event Log Create Event - Documentation on the event-log.create webhook event for monitoring errors Start Forgot Password Workflow API - API endpoint for triggering password reset emails programmatically

This error typically indicates a mismatch between the identity provider configuration and the authentication workflow being attempted.

Common causes:

Redirect URI mismatch — The redirect URI configured in your identity provider doesn't match what FusionAuth is sending during the authentication request. The redirect URI in your authentication request must exactly match one of the Authorized Redirect URLs configured in your application's OAuth configuration.

Identity provider type misconfiguration — The identity provider type (SAML v2, OpenID Connect, etc.) may not support the redirect-based flow being used

Missing or incorrect configuration — Required fields in the identity provider configuration may be missing or misconfigured

Wrong login method selected — If you're using the /api/identity-provider/login endpoint, ensure the correct Login Method is configured in the Identity Provider settings

Flow initiated from wrong starting point — The login flow must start at FusionAuth, not directly at the external Identity Provider. Going directly to a third-party IdP URL (e.g., directly to Google or Azure OAuth URLs) bypasses FusionAuth's session handling and will fail.

Resolution steps:

Verify the identity provider configuration in FusionAuth matches your external IdP settings exactly Check that redirect URIs are correctly configured on both sides — navigate to Applications → [Your Application] → OAuth tab and ensure the Authorized Redirect URLs are properly set Confirm the identity provider type supports the authentication flow you're attempting Enable debug mode on the Identity Provider (Settings → Identity Providers → [Your IdP] → Enable debug mode) and review FusionAuth event logs (System → Event Log) for more detailed error information If this started after a recent change, review what was modified in the identity provider configuration Ensure users are starting the login flow from FusionAuth's hosted login pages or proper OAuth authorize endpoint, not bypassing FusionAuth to go directly to the external IdP

If the issue persists, gather the full error details from the FusionAuth event log with debug mode enabled and review your identity provider configuration against the FusionAuth documentation for your specific IdP type.

Related Documentation Troubleshooting Identity Provider Configuration — General troubleshooting guide for IdP issues Add an OpenID Connect Identity Provider — Configuration guide for OIDC IdPs Host a SAML v2 Identity Provider — SAML configuration and troubleshooting Enabling Debugging — How to enable debug mode for detailed error logging Identity Provider APIs — API reference for programmatic IdP configuration

Currently, FusionAuth does not support forcing the register screen when prompt=login is used with an active SSO session. The screen_hint parameter (like Auth0's screen_hint=signup) is not available in FusionAuth.

Workarounds:

Clear the SSO session before registration: You can clear the existing SSO session in your proxy/middleware before redirecting to oauth2/register. While not ideal, this would allow the registration flow to proceed without the passthrough behavior.

Use direct registration without prompt: If you call the registration endpoint without the prompt=login parameter and there are no missing required fields, FusionAuth will complete the registration directly. Only when there are missing fields will users be sent to the complete-registration page.

Feature Request:

If neither workaround meets your needs, this would require a feature request for FusionAuth to support a parameter similar to screen_hint=signup. The product team would need to review this for the roadmap, though implementation timelines would depend on prioritization.

For now, clearing the SSO session before initiating registration is the most reliable approach to ensure users see the registration screen rather than experiencing passthrough behavior.

Related Documentation OAuth prompt Parameter - Details on the prompt=login parameter and its behavior (available since v1.60.0): OIDC Prompt Documentation OAuth Authorize Endpoint - Complete reference for OAuth authorization parameters including prompt, login_hint, and idp_hint: Authorize API Reference Self-Service Registration - Overview of how self-service registration works and how registrations are created: Self-Service Registration Guide Complete Registration - Information on the complete registration flow when missing fields are present (available since v1.65.0): Complete Registration Documentation Logout and Session Management - How to clear SSO sessions programmatically: Logout and Session Management Hosted Backend API - Documentation on the /oauth2/register endpoint behavior: Hosted Backend API

Note: The /oauth2/register endpoint is not fully documented in the official OAuth endpoints reference. There is an open issue to add complete documentation for this endpoint. When a user has an active SSO session and hits /oauth2/register, FusionAuth redirects them through the authorization flow, which causes the passthrough behavior you're experiencing.