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

For frequent, large-scale user resets in test environments, deleting and recreating the tenant is the recommended approach over bulk user deletion. While there's no "near-instant" bulk deletion method, tenant recreation is significantly faster than iterative bulk deletes at scale.

Key Points About Bulk Delete Delete Users by Query is driven by the search index (specifically Elasticsearch). The queryString parameter has limited support when using the database as the search engine (only simple single-term searches on basic fields like firstName, lastName, fullName, email, and username). CloudFront has a 30-second timeout for origin responses, which explains the 504 errors you're seeing The delete operation likely continues on the FusionAuth side even after CloudFront terminates the connection, making retries risky Recommended Approach: Tenant Delete/Recreate

For test environments with large user populations, follow this workflow:

Cannot delete the Default tenant — the default tenant contains the FusionAuth application and cannot be deleted. Create separate tenants for testing purposes. Delete the test tenant when ready to reset using the admin UI or the Delete Tenant API. This will permanently delete all users, applications, and groups belonging to that tenant. Use docker compose down -v to fully clean the environment Use docker compose up -d to restart Use Kickstart to automatically recreate tenants, applications, and API keys

Kickstart will only run on an empty instance, so the down -v step is necessary. Configure a Kickstart file with your test environment configuration (tenants, applications, API keys) for reproducible deployments.

Note that tenant deletion is an asynchronous operation (as of FusionAuth 1.22), meaning it runs in the background. For very large tenants (2M users), this will still take time but is considerably faster than bulk deleting millions of users through the API.

Note on Import Timeouts

If you're also seeing CloudFront timeouts during large batch imports (e.g., 100k users), the same 30-second CloudFront limit applies. Consider reducing batch sizes when users have multiple registrations, as each registration inserts additional rows into related tables (registrations, application role mappings, etc.), significantly increasing processing time. For best import performance, minimize network hops and consider setting validateDbConstraints to false.

Related Documentation Delete Tenant API - API for permanently deleting a tenant and all its users Bulk Delete Users API - API for deleting users by query, with limitations noted for search engine configuration Kickstart - Declarative tool for quickly replicating environments Clean Up Test Environments - Migration guide with recommendations for test tenant cleanup How to Delete Users After Testing a Migration - Documentation on fastest methods for removing test users Asynchronous Tenant Deletion - Background on how tenant deletion works asynchronously Import Users API - Bulk import API documentation Performance Tips for Migrations - Best practices for importing large numbers of users

Security notices are sent to users in your account.fusionauth.io portal who have been designated as a "Security Officer".

To ensure your team receives security advisories:

Log into account.fusionauth.io Assign the Security Officer role to anyone on your team who should receive security notifications There is no limit to the number of users you can assign this role to

This is documented in the FusionAuth security documentation.

By assigning this role to appropriate team members, you'll ensure that critical security advisories are delivered directly to your organization rather than relying on personal accounts.

You can retrieve all identity provider links for a user by sending a GET request to:

/api/identity-provider/link?userId={userId}

Important: The parameter name is case-sensitive and must be userId (with capital "I"), not userid.

The error you're seeing occurs when the parameter is lowercase userid instead of the correct camelCase userId. Using the correct casing will return a list of all identity provider IDs that the user is currently linked to.

Make sure your request looks like:

GET {baseUrl}/api/identity-provider/link?userId=4aa40fcd-0102-4c26-a51c-9a6c5c0c504a Authorization: <your-api-key>

This endpoint works with a standard API key and will return the identity provider link information you need to determine if a user is linked to external providers.

For FusionAuth Cloud deployments, you can obtain the outbound IP address list by opening a support ticket in the FusionAuth Account Portal and providing your deployment hostname.

Key facts about FusionAuth Cloud outbound IPs:

Complete list: FusionAuth will provide the complete list of outbound IP addresses for your specific deployment. These are the only addresses your deployment will use. Note that IP addresses are not exposed through the user interface—opening a support ticket is the only way to obtain them.

Static addresses: The outbound IP addresses are static and will not change during:

Upgrades Maintenance windows Normal scaling operations

For new FusionAuth Cloud deployments, static IP addresses are already configured. If the IP addresses ever need to change, FusionAuth will notify you in advance.

All outbound traffic: All outbound traffic from your FusionAuth Cloud deployment originates from the same set of IP addresses, including:

SMTP/email traffic Webhooks HTTP calls from Lambdas Any other outbound connections

You can safely use these IP addresses to configure firewall rules, SMTP server allowlists, and other security restrictions for services that need to accept connections from your FusionAuth Cloud deployment.

Important: The provided IP addresses should only be used to allow outbound traffic through firewalls and network control layers. Do not use them for HTTP/API calls, as they won't respond to such requests. In addition to IP allowlisting, consider using custom headers, TLS transport, and client certificates to further secure outbound traffic.

Related Documentation Deployment IP Addresses - Official documentation on obtaining IP addresses for FusionAuth Cloud deployments FusionAuth Account Portal - Support - How to access the support portal to request IP addresses FusionAuth Cloud Overview - General information about FusionAuth Cloud deployments

You are correct — FusionAuth can add SMTP headers under Tenant → Edit → Email → Advanced → Additional headers, but those headers apply to all emails sent for that tenant. There is currently no way to set headers per-user or per-email.

Your two workarounds are both valid approaches:

Option 1: SMTP Proxy

Route FusionAuth's outgoing SMTP traffic through an SMTP proxy or mail-relay service. Your proxy can inspect the recipient, determine their consent state, and inject the required tracking headers before final delivery.

Option 2: Webhooks + External Mailer (Recommended for full control)

Disable FusionAuth's built-in email templates and handle all email sending via webhooks to your own backend or third-party mailer. This gives you complete control over templating, state checking, and headers per user.

Webhook-based flow:

Disable the built-in email templates in FusionAuth so it doesn't send anything itself. Navigate to Tenants → Edit → Email → Templates and set each template to disabled or leave it unassigned. You can also configure this at the application level under Applications → Your Application → Email → Templates to override tenant-level settings.

Set up webhooks under Settings → Webhooks, pointing to your backend endpoint. Enable the specific events you need.

Your backend listens for events, pulls relevant data from the webhook payload, checks user consent state, and sends the email through your own mailer with appropriate headers.

Key webhook events and payloads: Email Verification: verificationId to build the verification link Forgot Password: changePasswordId to build the reset link Setup Password: check user.password is null to confirm they need setup Breached Password (user.password.breach😞 user.email to notify them to change their password Suspicious Login (user.login.suspicious😞 event.info for device and location details (Enterprise feature) Registration Verification (user.registration.verified😞 verificationId to build the verification link MFA Method Added/Removed: method object with the method type and identifier

Important: If you use the webhook approach, make sure to disable all relevant email templates in FusionAuth. If you leave some templates enabled while your third-party mailer is active, users will receive duplicate emails — one from FusionAuth and one from your mailer.

Related Documentation Configure SMTP - Custom Headers - Information on configuring tenant-level SMTP settings including additional headers Announcing FusionAuth 1.32 - Custom Email Headers - Details on the custom email headers feature added in version 1.32 Events & Webhooks - Complete documentation on FusionAuth's webhook system Email Templates - Managing and disabling email templates Application-Specific Email Templates - Overriding email templates at the application level User Login Suspicious Event - Webhook payload for suspicious login events User Password Breach Event - Webhook payload for breached password events User Registration Verified Event - Webhook payload for registration verification events

Yes, FusionAuth Cloud uses static outbound IP addresses that you can whitelist in your downstream services. The specific IPs depend on your deployment's region.

These IP addresses are static and will not change under normal circumstances. If FusionAuth ever needs to modify or add to these addresses, customers will receive advance notification.

To obtain the specific outbound IPs for your region, you'll need to open a support ticket through the FusionAuth Account portal with your deployment name and details.

Important Notes:

New deployments receive static outbound IPs by default. If you have an existing deployment created before static IPs were standard, you may need to request them via support ticket. The provided IP addresses are intended only for allow-listing outbound traffic (such as SMTP services, webhooks, LDAP connectors, etc.). These IPs should not be used to make inbound API calls, as they won't respond to such requests. Static IPs are available for all FusionAuth Cloud deployments, including both standard and High Availability (HA) configurations. Related Documentation FusionAuth Cloud - Deployment IP Addresses - Official documentation on obtaining IP addresses for your deployment FusionAuth Cloud - Support - How to access support and open tickets for IP address requests FusionAuth Cloud Overview - General information about FusionAuth Cloud hosting

This is going to vary based on your publishing system, but you can use FusionAuth's OIDC prompt=none to see if users have an active SSO session.

If the user has checked remember me and has logged in within the tenant session timeout, the request will succeed, otherwise it will fail.

Step 1: Main Page

This creates the iframe and listens for the result.

On your main page, create the hidden iframe targeting FusionAuth with prompt=none. You also listen for a message event from the iframe to know whether to display or hide the CTA <div>, which needs the id trial-cta:

// 1. Listen for the result sent back from the iframe callback page window.addEventListener('message', (event) => { // Verify the origin matches your application domain for security if (event.origin !== window.location.origin) { return; } const ctaDiv = document.getElementById('trial-cta'); if (event.data && event.data.type === 'SILENT_AUTH_RESPONSE') { if (event.data.status === 'authenticated') { // User has an active SSO session; keep CTA hidden if (ctaDiv) { ctaDiv.style.display = 'none'; } } else if (event.data.status === 'login_required') { // User is not authenticated; show the trial CTA popup/div if (ctaDiv) { ctaDiv.style.display = 'block'; } } } }); // 2. Create the hidden iframe to initiate the prompt=none request const iframe = document.createElement('iframe'); iframe.style.display = 'none'; iframe.src = 'https://<your-fusionauth-instance>/oauth2/authorize?' + 'client_id=<YOUR_CLIENT_ID>&' + 'response_type=code&' + 'redirect_uri=https://<your-app-domain>/silent-callback.html&' + 'scope=openid&' + 'prompt=none&' + 'state=<YOUR_STATE>'; document.body.appendChild(iframe); Step 2: Callback Page

Configure this page as an authorized redirect URI in your FusionAuth application [Request Parameters].

When FusionAuth redirects back with the authorization code code or error=login_required, this page parses the URL and communicates back to the parent window:

// Parse query parameters from the redirect URI const params = new URLSearchParams(window.location.search); const code = params.get('code'); const error = params.get('error'); if (code) { // Session exists: notify the parent window window.parent.postMessage({ type: 'SILENT_AUTH_RESPONSE', status: 'authenticated', code: code }, window.location.origin); } else if (error === 'login_required') { // No active session: notify the parent window to show CTA window.parent.postMessage({ type: 'SILENT_AUTH_RESPONSE', status: 'login_required' }, window.location.origin); } Cautions And Additional Considerations

This won't work across all browsers, especially those with privacy features or if your FusionAuth instance isn't on the same root domain as the application. More details here.

Test the scenarios you need to support.

The CTA should include information about how to sign up or log in if the user already has an account.

You may want to add server or client side logic to obfuscate the page contents.

This is expected behavior for certain authentication flows in FusionAuth. When authentication happens via methods like refresh token grants, SSO handoffs, or silent authentication (where the user already has an active session), the event may not include an applicationId because the authentication isn't directly tied to a specific application registration at that moment.

Workarounds and Best Practices 1. Check the JWT for Application Context

Your applications should be validating the JWT claims after authentication, including:

applicationId (or aud claim) — identifies which application the token was issued for Other application-specific claims

See JWT Components Explained for details on these claims.

2. Enable Automatic Registration on Proxy Applications

If you're using a proxy or gateway application that performs authentication on behalf of other applications, enable automatic registration for that proxy application. This ensures users are properly registered to the proxy app, which can help maintain application context.

Refer to the Application Suite edge cases documentation for scenarios where this pattern is useful.

3. Alternative Event Sources

For complete application attribution, consider:

Using user.registration.create events when users first register to applications Combining user.login.success events with application-level audit logs Implementing custom event enrichment in your webhook consumer that correlates login events with subsequent token validation Important Note

Self-service registration, if enabled, allows anyone to register to that application. Your applications should always validate that the user has a proper registration (jwt.applicationId) and any other business-specific claims required for access.

The user.update.complete event intentionally does not fire when the verified flag changes through email verification. This is by design.

Email verification is considered a distinct workflow separate from the general user update process in FusionAuth's event model. As noted in a related GitHub issue, the decision was made to introduce dedicated verification events rather than triggering user.update.complete because email verification "does not occur due to the Update User API, but because of a separate workflow." The user.update.complete event is reserved for changes made through the Update User API, while verification-specific changes trigger their own dedicated events.

Recommended Solution

You should listen to these specific webhook events for verification state changes:

user.email.verified — fires when an email address is verified (available since 1.8.0) user.identity.verified — fires when an identity (email or phone number) is verified (available since 1.59.0) Handling Race Conditions

If you're concerned about race conditions when multiple events fire simultaneously:

Adjust your Kafka partitioning strategy to key on userId — this ensures all events for the same user go to the same partition and are processed in order Use event timestamps in your downstream consumers to deduplicate or order events correctly. Each event includes a createInstant field in the event object that can be used for ordering Design your sync logic to be idempotent so that processing events out of order doesn't cause inconsistent state

The separate user.email.verified and user.identity.verified events provide more granular control over what verification changes you respond to, which is generally more useful than a generic user update event.

Related Documentation User Update Complete Event — documentation for the user.update.complete event User Email Verified Event — documentation for the user.email.verified event User Identity Verified Event — documentation for the user.identity.verified event Kafka Integration — comprehensive guide to FusionAuth's Kafka integration for consuming webhook events Webhook Event Log — review events sent by FusionAuth with timing and result information

Yes, this is possible with some configuration adjustments.

The key insight is that you can use an MFA requirement lambda to selectively enforce MFA during login based on user attributes (like a user type or role), while still allowing all users to participate in step-up authentication flows later. The MFA requirement lambda is an enterprise plan feature.

Recommended Approach Configure MFA methods for all users (both staff and non-staff), but differentiate their login behavior using an MFA requirement lambda Set the tenant MFA login policy to something like Required or Enabled Create an MFA requirement lambda that: Returns true (require MFA) for staff users Returns false (skip MFA) for other user types during login

This way:

Staff users will be challenged for MFA on every login Non-staff users will skip MFA during login but still have MFA methods configured All users can participate in step-up authentication flows when your application calls the step-up APIs, because they all have MFA methods available Example Lambda Logic function checkRequired(result, user, registration, context) { // assumes there's a role assigned to the user registration. could also examine other attributes or make a fetch call var userRoles = registration && registration.roles || []; if (userRoles.includes('staff')) { result.required = true; } else { result.required = false; } }

This approach delegates the step-up authentication flow and code sendout completely to FusionAuth while maintaining your login MFA requirements.

The /oauth2/logout endpoint only removes the SSO session (the front-channel session controlled by the "Keep Me Signed In" toggle). It does not automatically revoke the refresh token (also known as offline_access).

To properly implement logout, you need to handle both sessions separately:

Recommended Logout Flow User initiates logout in your application Your backend revokes the refresh token using the Revoke Refresh Tokens API:DELETE /api/jwt/refresh/{refreshTokenId} Or revoke by user and application:DELETE /api/jwt/refresh?userId={userId}&applicationId={applicationId} Destroy your local application session (clear tokens, cookies, etc.) Redirect to /oauth2/logout with id_token_hint to clear the SSO session Why This Approach?

Revoking the refresh token from your application (step 2) is better than relying on the logout URL callback because:

You have direct access to the user's session data You know exactly which refresh token to revoke You can handle errors gracefully The flow is more deterministic

The /oauth2/logout endpoint can call a logout URL configured in your FusionAuth OAuth application settings, but handling revocation proactively in your app provides better control.

Important Note About JWTs

Since JWTs (access tokens) are stateless, they cannot be immediately revoked by FusionAuth. If you need to invalidate JWTs before their natural expiration, you'll need to implement your own revocation strategy, such as maintaining a token denylist in your application.

Related Documentation OAuth Logout API - Details on the /oauth2/logout endpoint Revoke Refresh Tokens API - How to revoke refresh tokens programmatically Logout and Session Management - Comprehensive guide on logout strategies and session types Revoking JWTs - Strategies for JWT revocation JWT Refresh Token Revoke Event - Webhook event when refresh tokens are revoked