FusionAuth
    • Home
    • Categories
    • Recent
    • Popular
    • Pricing
    • Contact us
    • Docs
    • Login
    1. Home
    2. FASupportBot
    3. Topics
    F
    • Profile
    • Following 0
    • Followers 0
    • Topics 72
    • Posts 144
    • Best 0
    • Controversial 0
    • Groups 0

    Topics created by FASupportBot

    • F

      Solved WebAuthn passkey registration fails on Android with origin validation error in 1.69.2

      Frequently Asked Questions (FAQ)
      • webauthn passkey android credential manager • • FASupportBot
      2
      0
      Votes
      2
      Posts
      54
      Views

      F

      This is a confirmed bug in FusionAuth 1.69.2. The issue is in how FusionAuth validates the origin from clientDataJSON during WebAuthn registration.

      This has been fixed and will be released in the next release. Subscribe to the release announcements to be notified when that happens.

    • F

      Solved Is `auth_time` in refresh token metadata reliable for MFA + PASSWORD flows?

      Frequently Asked Questions (FAQ)
      • refresh-token metadata mfa authentication api • • FASupportBot
      2
      0
      Votes
      2
      Posts
      30
      Views

      F

      The data sub-object containing auth_time and authentication_type in refresh token metadata is not currently a documented or officially supported feature in FusionAuth. Its presence is inconsistent across authentication flows, as you've observed — it appears for some authentication types but not others (notably absent for MFA + PASSWORD flows).

      According to the official documentation, the only documented fields within refresh token metaData are:

      metaData.device — An object containing device information (name, type, description, lastAccessedAddress, lastAccessedInstant) metaData.scopes — An array of OAuth scopes associated with the token metaData.resources — An array of resource URIs per RFC 8707 (available since v1.67.0)

      The data sub-object with auth_time and authentication_type that you're observing is not part of the documented API contract. Because this is undocumented behavior, you should not rely on it in production code, as it may change or be removed in future versions without notice.

      Important Distinction: auth_time on JWTs vs Refresh Tokens

      Note that auth_time is a standard and documented claim on access tokens and ID tokens (the JWTs themselves), where it represents the time of initial authentication. However, it is not a documented field on the refresh token record itself when queried via the retrieval API.

      Related Documentation Retrieve Refresh Tokens API — Official API documentation including the complete response body structure for refresh tokens Access Token and ID Token Claims — Where auth_time is officially documented as a JWT claim Multi-Factor Authentication (MFA) — Guide to implementing MFA in FusionAuth JWT Refresh API — How to use refresh tokens to obtain new access tokens
    • F

      Solved How are FusionAuth Cloud deployments sorted in the account portal?

      Frequently Asked Questions (FAQ)
      • cloud account-portal deployments feature-request • • FASupportBot
      2
      0
      Votes
      2
      Posts
      43
      Views

      F

      Currently, there is no sorting logic implemented for deployments in the FusionAuth Cloud account portal. The order of deployments is not sorted alphabetically or by any other consistent criteria at this time.

      This has been noted as a feature request to add sorting capabilities (or the ability to manually sort) deployments in the account portal. This would help prevent accidental selection of the wrong instance when managing multiple FusionAuth Cloud deployments.

      In the meantime, extra care should be taken when selecting deployments from the list to ensure you're working with the correct instance. You can use the Rename feature (available in the Action dropdown menu for each deployment) to give your deployments descriptive names that help distinguish between different products or environments.

      Related Documentation Managing Your Deployments - Overview of managing FusionAuth Cloud deployments in the account portal The Account Portal - Documentation on accessing and using the account portal FusionAuth Account Portal Reference - Complete reference for the FusionAuth account portal features
    • F

      Solved How to get static outbound IP addresses for FusionAuth Cloud email delivery?

      Frequently Asked Questions (FAQ)
      • fusionauth cloud email smtp static-ip • • FASupportBot
      2
      0
      Votes
      2
      Posts
      46
      Views

      F

      FusionAuth Cloud deployments can provide static outbound IP addresses for email delivery and other outbound connections. The availability and process depend on when your deployment was created.

      Getting Static IP Addresses

      For new FusionAuth Cloud deployments: Static IP addresses are already configured automatically.

      For existing deployments: You need to open a support ticket to get static IP addresses assigned.

      How to Request Your Deployment's IP Addresses

      To retrieve the specific outbound IP addresses for your deployment (e.g., to allowlist them with your SMTP provider):

      Open a support ticket Include the name of the deployment for which you need the outbound IP addresses

      Once assigned, these IP addresses will remain static and won't change during upgrades, restarts, or normal operations.

      Important Notes About the IP Addresses The provided IP addresses are for outbound traffic only (firewalls, allowlists, SPF records, etc.) — they will not respond to HTTP API calls You should add these IPs to your SPF DNS record for your sending domain to prevent password reset and other transactional emails from landing in spam Multiple IP addresses may be provided for high availability Recommended Approach

      If you have both production and development environments:

      Request and configure the static IPs for your development instance first Test email delivery with the allowlisted IPs Once verified, request and configure the production deployment's static IPs Related Documentation FusionAuth Cloud - Deployment IP Addresses - Official documentation on obtaining IP addresses for your FusionAuth Cloud deployment Configure SMTP - Complete guide to configuring email delivery in FusionAuth SMTP Best Practices - Recommendations for maintaining good sender reputation including SPF records GitHub Issue #1393 - Original feature request for static IP addresses in FusionAuth Cloud
    • F

      Solved Remember Me checkbox not working — users logged out after one hour despite being checked

      Frequently Asked Questions (FAQ)
      • remember-me oauth session device-trust tenant • • FASupportBot
      2
      0
      Votes
      2
      Posts
      20
      Views

      F

      The behavior you're experiencing is likely related to the SSO Session Timeout setting in your Tenant configuration.

      Understanding the "Remember Me" Checkbox

      The "Remember Me" checkbox (labeled "Keep me signed in" in the default theme) controls the FusionAuth SSO session. When checked, it creates a persistent cookie that allows users to remain logged in across browser sessions. However, even with this option checked, the session will still expire based on your configured Session Timeout value.

      Check Your SSO Session Timeout

      Navigate to:

      Tenants → (your tenant) → OAuth tab Look for the Session timeout setting The default value is 3600 seconds (1 hour)

      This setting controls how long the FusionAuth SSO session remains valid. When this duration expires, users are logged out and must re-authenticate, even if they previously selected "Remember Me."

      The one-hour expiration you're seeing matches the default Session Timeout setting, which explains why users are consistently logged out after that time period.

      To Resolve This Issue Increase the Session timeout value to a longer period (e.g., 86400 seconds for 24 hours, 2592000 seconds for 30 days, or whatever suits your security requirements) Save the Tenant configuration Have users log in again with "Remember Me" checked

      The new timeout will apply to all new SSO sessions created after the configuration change.

      Related Documentation Logout and Session Management - SSO Session Timeouts FusionAuth Cookies Reference Does FusionAuth support Remember Me functionality? Configure Session Timeout
    • F

      Solved Can I use AWS SNS Notify for SMS MFA with FusionAuth Generic Messenger?

      Frequently Asked Questions (FAQ)
      • mfa sms generic messenger aws • • FASupportBot
      2
      0
      Votes
      2
      Posts
      30
      Views

      F

      Yes, this is feasible, but you cannot integrate AWS SNS Notify directly with FusionAuth's Generic Messenger. You'll need to implement a middleware relay to bridge the two systems.

      Architecture

      The Generic Messenger can only POST JSON to a URL, while AWS Notify requires AWS-signed API calls. The solution is to place a relay service between FusionAuth and AWS SNS.

      Recommended approach:

      Set up an AWS API Gateway endpoint backed by a Lambda function as your relay Configure FusionAuth's Generic Messenger to POST to this API Gateway endpoint The Lambda function receives the phone number and message from FusionAuth The Lambda extracts the MFA code from the payload The Lambda calls AWS SNS SendNotifyTextMessage with the code as a template variable AWS SNS delivers the SMS using your pre-approved template Important constraint

      You must configure AWS Notify to use "you generate the code" mode, because FusionAuth generates and validates its own MFA codes internally.

      Additionally, AWS SNS Notify only sends pre-approved message templates for compliance reasons, so FusionAuth's custom message wording will not reach the end user — only the MFA code itself will be inserted into your AWS template.

    • F

      Solved How to audit if application authentication tokens have been used for login?

      Frequently Asked Questions (FAQ)
      • authentication tokens api login-records audit • • FASupportBot
      2
      0
      Votes
      2
      Posts
      34
      Views

      F

      Login records in FusionAuth (via the Login Report) don't distinguish between authentication methods. The response fields include applicationId, applicationName, loginId, loginIdType, instant, ipAddress, and userId, but none indicate the credential type used (token vs. password vs. SSO).

      Recommended Approach

      You can determine token usage by checking the lastLoginInstant field on user registrations:

      Use the Retrieve User Registration endpoint (GET /api/user/registration/{userId}/{applicationId}) or search for users with tokens For each registration with an authenticationToken, check the lastLoginInstant against your time windows (30 days, 90 days, 1 year) If lastLoginInstant falls within your time window for any user, someone authenticated to that application during that period

      Here's a Python script approach:

      import requests from datetime import datetime, timedelta # Define time windows windows = { '30d': datetime.now() - timedelta(days=30), '90d': datetime.now() - timedelta(days=90), '1y': datetime.now() - timedelta(days=365) } # Pull registrations for your application # Check each registration's lastLoginInstant against cutoffs # Count how many fall within each window

      If all time windows return 0 users: Nobody authenticated to that application during those periods, so the tokens weren't used.

      If users show up: The lastLoginInstant can't distinguish whether they used the token, password, or SSO. In this case, you have two additional options:

      Check proxy/application logs for /api/login API calls and examine the request body to see if loginId and password were provided, or if it was a token-based authentication

      Check webhook events: If you have webhooks configured, examine user.login.success events for the authenticationType field. When a user authenticates with an application authentication token, the value will be APPLICATION_TOKEN. Other possible values include PASSWORD, REFRESH_TOKEN, identity providers like GOOGLE or FACEBOOK, and many more.

      Check JWTs: If you capture or log JWTs, the access token contains an authenticationType claim that indicates the authentication method used. For authentication tokens, this will be set to APPLICATION_TOKEN.

      Related Documentation Application Authentication Tokens - Overview of application authentication tokens and how they work Retrieve a User Registration API - API documentation for retrieving user registration details including authenticationToken and lastLoginInstant Search Login Records API - API for searching login records (note: does not include authenticationType) User Login Success Event - Webhook event that includes authenticationType field Authentication Types Reference - Complete list of authentication types including APPLICATION_TOKEN, PASSWORD, and others Login API - API for authenticating users with various methods including authentication tokens
    • F

      Solved How to redirect users from FusionAuth 404 error page?

      Frequently Asked Questions (FAQ)
      • 404 themes customization reverse-proxy error-handling • • FASupportBot
      2
      0
      Votes
      2
      Posts
      127
      Views

      F

      Unfortunately, there is no built-in way to customize the 404 page via FusionAuth themes to force a redirect. The standard theme editor does not include a template for the 404 error page, and this functionality is not currently supported.

      The recommended approach is to:

      Investigate the root cause: Try to determine what circumstances are causing users to hit the 404 page. If you can replicate the issue, identifying the source will help prevent it from occurring.

      Use a reverse proxy: If you need to redirect users away from the 404 page, the recommended solution is to set up a reverse proxy (such as nginx, Apache, or similar) in front of FusionAuth that can intercept 404 responses and redirect users to an appropriate page. For example, with nginx, you can use the proxy_intercept_errors directive to handle error responses.

      It's generally better to address why users are reaching the 404 page rather than simply redirecting them away from it, as this may indicate an underlying issue with URL construction, deep linking, or session handling in your application.

      Related Documentation Themes Overview - Learn about FusionAuth's theme customization capabilities Troubleshooting Proxies - Important guidance when using FusionAuth behind a reverse proxy 404 Page Theme Forum Discussion - Community discussion confirming this limitation GitHub Issue #404 - Feature request for customizable error pages (consider upvoting if this is important to you)
    • F

      Solved Why am I receiving two MFA codes during password reset flow?

      Frequently Asked Questions (FAQ)
      • mfa password-reset gmail email theme • • FASupportBot
      2
      0
      Votes
      2
      Posts
      95
      Views

      F

      This issue is related to Gmail's safe-links protection feature, which scans links in emails for security purposes.

      Root Cause

      When Gmail scans the password reset button/link, it fires two GET requests to the /password/change endpoint:

      One request from Gmail's link scanner One request from the actual user click

      Each request triggers the MFA code generation, resulting in two codes being sent.

      Why FusionAuth's Normal Protections May Not Apply

      FusionAuth has built-in protections against email link scanners consuming codes or triggering duplicate actions. Starting with version 1.49.0, FusionAuth introduced a mandatory confirmation page that requires user interaction when a link request doesn't originate from the same browser that initiated the workflow. This prevents most link scanners (including aggressive ones like Outlook Safe Links) from consuming codes.

      However, this protection may not engage if:

      Custom theme is missing the confirmation template — If you're using a custom theme, you need to copy the "Confirmation required" template (/confirmation-required) into your theme to benefit from this feature. Without it, the protection doesn't work. The user recently changed their password and has "confirmation trust" already established in their browser A proxy between the client and FusionAuth is not properly handling cookies that prevent link checker issues The state parameter is being mangled in a custom theme, causing unexpected behavior Solutions

      Add the Confirmation Required Template to Your Custom Theme — This is likely the primary fix. The confirmation required template was added in version 1.49.0 and must be manually added to custom themes. Copy it from the default theme to ensure link scanners are blocked from triggering duplicate MFA codes.

      Upgrade to the Latest Version of FusionAuth, which includes the most recent fixes for link scanner issues

      Review Custom Theme Modifications — Compare your theme files against the stock FusionAuth theme to ensure the state parameter and form structure haven't been altered in ways that bypass protections

      Check Proxy Configuration — Ensure any proxy in front of FusionAuth is correctly forwarding cookies and not causing duplicate page renders

      Test with Default Theme — Verify the issue doesn't occur with default templates to isolate whether customizations are the cause (you've already confirmed this resolves the issue)

      Why Subsequent Attempts Work

      After the first password reset attempt, browser state and cookies are properly established, preventing the duplicate request issue on subsequent attempts from the same session.

      Why Button vs Link Matters

      The difference between button and link behavior may be related to how your custom theme implements these elements. Buttons might use different form submission methods or lack the postMethod=true parameter that converts GET requests to POST requests (which link scanners typically don't replicate).

      Related Documentation Confirmation Required Template Variables — Details on the confirmation required template introduced in version 1.49.0 Email Link Workflow Improvements (FusionAuth 1.49) — Explains the confirmation page feature designed to prevent link scanners from consuming codes FusionAuth Cookies Reference — Information about cookies used by FusionAuth's hosted login pages GitHub Issue #2253: Email MFA codes sent multiple times during password resets — Related issue about duplicate MFA codes Community Discussion: Password Reset Expired Link - Safelinks Users — Discussion about link checker issues with password reset flows
    • F

      Solved How to track progress when deleting a large tenant in FusionAuth?

      Frequently Asked Questions (FAQ)
      • tenant deletion bulk-operations performance • • FASupportBot
      2
      0
      Votes
      2
      Posts
      94
      Views

      F

      Unfortunately, there is no built-in way to measure or track the progress of a tenant deletion in FusionAuth.

      When you delete a tenant, FusionAuth must bulk delete all users within that tenant. If the tenant contains a large number of users (hundreds of thousands or millions), this operation can take considerable time to complete.

      The UI will display "Deleting..." during this process, but there is no progress bar or percentage indicator available. The deletion will complete eventually, but the duration depends entirely on the number of users in the tenant.

      For very large tenants, be prepared for the deletion to run for an extended period without visible progress updates.

      Alternative Approaches

      Monitor Application Logs

      While there's no built-in progress indicator, you can monitor FusionAuth's application logs for messages from the AsyncTaskManager. The logs will show when the deletion task completes:

      [DeleteTenant] task for [tenantId] has completed successful.

      If there are issues, you may also see failure messages in the logs that indicate the deletion needs to be retried.

      Use the API with Async Mode

      If you're deleting the tenant programmatically, you can use the Delete a Tenant API with the async=true parameter:

      DELETE /api/tenant/{tenantId}?async=true

      This returns a 202 Accepted response immediately rather than waiting for completion. The deletion then runs in the background. This asynchronous mode is especially useful for tenants with millions of users to avoid client timeouts. You can periodically poll the tenant list via the API to check if the tenant still exists—once it disappears, the deletion is complete.

      Related Documentation Delete a Tenant API - Official API documentation for tenant deletion with async option Asynchronous Tenant Deletion - Blog post announcing async tenant deletion feature in version 1.22 Tenant Manager API - General tenant management API documentation
    • F

      Solved How to restrict FusionAuth admin panel access to specific IP addresses?

      Frequently Asked Questions (FAQ)
      • admin-panel ip-whitelist access-control security acl • • FASupportBot
      2
      0
      Votes
      2
      Posts
      112
      Views

      F

      Recommended Approaches for FusionAuth Cloud

      Since you're using FusionAuth Cloud, here are your options for restricting admin panel access:

      Use IP ACLs

      You can use the IP ACLs and assign them to the FusionAuth application, which represents the FusionAuth admin UI.

      These are an enterprise only feature, so if you are not on that plan, you can't use IP ACLs.

      Additional Security Layers

      While these don't replace IP restrictions, they add defense in depth:

      Tenant Separation: Move all non-admin users to a separate tenant, keeping the default tenant for administrators only Strong MFA: Require multi-factor authentication for all admin users API Key Security: If you use IP ACLs with API keys (see below), you can restrict which IPs can use specific API keys What IP ACLs ARE Good For

      While IP ACLs don't protect the admin UI directly, they're still valuable for:

      Restricting application access - Apply an IP ACL to specific applications to limit which IPs can authenticate to those apps Restricting tenant access - Apply an IP ACL to a tenant to limit logins across all applications in that tenant Restricting API key usage - Apply an IP ACL to API keys to limit which IPs can use them

      To configure an IP ACL:

      Navigate to Settings > IP Access Control Click the + icon to create a new ACL Add IP ranges and specify whether to allow or block them Set a default action (allow or block) for IPs that don't match any defined range Assign the ACL to an Application, Tenant, or API Key Emergency Access / Lockout Prevention

      Before implementing any IP restrictions (whether via proxy or IP ACLs):

      Create a backup API key with full admin privileges that you store securely Test your configuration from an allowed IP address first Document your IP ranges and keep them updated Have a rollback plan - If using a proxy, ensure you can quickly remove or modify the IP restrictions

      If you do get locked out:

      With IP ACLs on API keys/tenants: Use an unrestricted API key to call the FusionAuth API to modify or remove the ACL Last resort: Contact support (Cloud) Related Documentation Advanced Threat Detection - IP Access Control Lists IP Access Control List API Networking Configuration (Trusted Proxies) FusionAuth Cloud Deployment Community Forum: Restricting Admin Panel Access
    • F

      Solved How do I add IP addresses to the FusionAuth Cloud allow list?

      Frequently Asked Questions (FAQ)
      • cloud networking ip-allowlist api configuration • • FASupportBot
      2
      0
      Votes
      2
      Posts
      268
      Views

      F

      FusionAuth Cloud can add IP addresses to your instance's allow list if they meet the following criteria:

      Static: The IP address must be static and not change without notice. Owned by your organization: The IP must be allocated to your company's infrastructure, not shared with other companies or resources (such as through a CDN). Associated with production servers: The IP must be used by production servers, not developer laptops or office networks.

      Once you confirm your IP addresses meet these criteria, open a support ticket through your FusionAuth account portal with:

      The list of IP addresses to be added Confirmation that each criterion is met The FusionAuth Cloud hostname your application connects to

      FusionAuth will then add the addresses to your allow list. Note that if you use shared network infrastructure (like NAT gateways), all traffic from that infrastructure will share the same outbound IP, which is acceptable as long as the criteria above are met.

      Important notes:

      Allow list changes typically take two to three business days to implement Adding IPs to the allow list helps prevent 429 response codes and CAPTCHA challenges that may occur due to FusionAuth Cloud's rate limiting protections If you no longer need an IP address on the list, you can submit a support ticket to have it removed Related Documentation FusionAuth Cloud CAPTCHA and Rate Limits - Detailed information about IP allow lists and rate limiting FusionAuth Cloud Support - How to access support for your FusionAuth Cloud deployment FusionAuth Cloud Deployment IP Addresses - Information about IP addresses for your FusionAuth Cloud instances
    • F

      Solved How can I customize email templates per tenant without duplicating templates?

      Frequently Asked Questions (FAQ)
      • email-templates multi-tenant freemarker customization branding • • FASupportBot
      2
      0
      Votes
      2
      Posts
      239
      Views

      F

      Yes, you can use FreeMarker logic in FusionAuth email templates to dynamically customize content per tenant without duplicating templates.

      Solution

      Store tenant-specific branding data in the tenant.data field (custom JSON). For example:

      { "branding": { "logoUrl": "https://cdn.example.com/acme/logo.png", "primaryColor": "#0057b8", "buttonTextColor": "#ffffff", "subjectPrefix": "[Acme]", "supportEmail": "help@acme.com", "companyName": "Acme" } }

      Then reference this data in your email templates using FreeMarker syntax. Here's an example for email verification:

      [#assign b = (tenant.data.branding)!{}] [#assign color = b.primaryColor!"#333333"] <div style="font-family: Arial, sans-serif;"> <img src="${b.logoUrl!'https://cdn.example.com/default-logo.png'}" alt="${b.companyName!tenant.name}" height="40"> <p>Hi ${user.firstName!'there'},</p> [#if verificationOneTimeCode??] <p>Your verification code:</p> <p><strong>${verificationOneTimeCode}</strong></p> [#else] [#assign url = "${baseUrl}/email/verify/${verificationId}?client_id=${(application.oauthConfiguration.clientId)!''}&tenantId=${tenant.id}"] <a href="${url?html}" style="background:${color}; color:${b.buttonTextColor!'#ffffff'}; padding:12px 24px; text-decoration:none; border-radius:4px;"> Verify email </a> [/#if] </div> How it works [#assign b = (tenant.data.branding)!{}] safely extracts the branding object or defaults to an empty object ${b.logoUrl!'default-value'} provides fallback values if a property is missing The same template works across all tenants, pulling each tenant's specific branding from tenant.data

      This approach works for all FusionAuth email templates (email verification, forgot password, email MFA). The complexity and depth of customization you can achieve depends on your specific needs, but this pattern handles most common branding requirements.

      There's no form for editing tenant data, but you can do so using one of the client libraries and your own custom form.

    • F

      Solved Is the user/registration endpoint safe for concurrent calls?

      Frequently Asked Questions (FAQ)
      • api user registration concurrency race-condition • • FASupportBot
      2
      0
      Votes
      2
      Posts
      197
      Views

      F

      The /api/user/registration endpoint can be problematic when called concurrently for the same user. FusionAuth recommends using sequential calls.

      Recommendation: Make your registration calls sequentially, one after another, even though it may take slightly longer. This ensures data consistency and avoids potential conflicts or failures during the registration process.

      There is currently no single API call to atomically register a user to multiple applications. Each registration to an application requires a separate API call, and sequential execution is the safest approach.

      Related Documentation User Registration API - Overview of the registration API and available operations Create a User Registration (for an existing user) - API documentation for creating registrations Registrations Core Concept - Understanding the relationship between Users and Applications Applications - Core concepts about Applications in FusionAuth Registering a user to other applications during registration - Community discussion on this topic
    • F

      Solved Can Passkeys be used as an MFA method alongside email and authenticator app?

      Frequently Asked Questions (FAQ)
      • mfa passkeys webauthn authentication two-factor • • FASupportBot
      2
      0
      Votes
      2
      Posts
      372
      Views

      F

      Unfortunately, Passkeys cannot currently be used as an MFA method in FusionAuth's native hosted MFA flow. There is an open feature request for this functionality.

      Workaround

      You can implement a step-up authentication pattern using FusionAuth's WebAuthn API:

      After the user completes email + password login, your application calls /api/webauthn/start The authenticator produces a signature Your application calls /api/webauthn/assert to verify possession of the passkey Only grant access if the assertion succeeds

      You can check whether a user has a registered passkey by calling /api/webauthn?userId={userId}.

      Important limitation: This workaround runs in your application code, not inside FusionAuth's hosted MFA screen. Passkeys will not appear alongside email and authenticator app in the same native picker — you would need to build that UI and enforcement logic yourself in your application.

      A feature request has been logged for native passkey MFA support in FusionAuth's hosted flow.

      Related Documentation Authentication With WebAuthn & Passkeys - Complete guide to implementing WebAuthn/passkeys in FusionAuth WebAuthn API Reference - API endpoints for starting and completing WebAuthn authentication ceremonies Start a WebAuthn Passkey Assertion - Documentation for the /api/webauthn/start endpoint Retrieve a Passkey - How to check if a user has registered passkeys using /api/webauthn?userId={userId} Multi-Factor Authentication (MFA) - Overview of FusionAuth's native MFA methods (TOTP, email, SMS) Step-Up Authentication - General guidance on implementing step-up auth patterns in FusionAuth Can I do a step up authentication with WebAuthn/passkeys? - Community discussion on this exact use case
    • F

      Solved Can passwordless login code TTL be configured per application instead of per tenant?

      Frequently Asked Questions (FAQ)
      • passwordless configuration api tenant login-flow • • FASupportBot
      2
      0
      Votes
      2
      Posts
      354
      Views

      F

      Unfortunately, the passwordless login code TTL cannot be configured per application—it is only available as a tenant-level setting in FusionAuth. The default TTL is 180 seconds, and this is configured via tenant.externalIdentifierConfiguration.passwordlessLoginTimeToLiveInSeconds.

      Here are two potential workarounds:

      1. Separate Tenants

      Since the setting is per tenant, you could place applications that require different code lifetimes into separate tenants. Note that this means users and configuration will be isolated per tenant, so carefully evaluate whether this trade-off fits your architecture.

      2. Build Your Own Passwordless Flow

      You can implement custom code expiration logic by using the passwordless API directly:

      Start the login with /api/passwordless/start Deliver the code through your own mechanism Track when you issued each code in your application Enforce your desired per-application expiry by rejecting codes that are too old before calling the completion endpoint Complete the login with /api/passwordless/login

      With this approach, the tenant-level TTL acts as the maximum lifetime, but your application logic can enforce shorter, application-specific expirations as needed.

      This is not a built-in FusionAuth feature, so if per-application passwordless code TTL is important to your use case, consider submitting a feature request on the FusionAuth GitHub issues page.

      Related Documentation Passwordless Login Overview - General overview of passwordless authentication in FusionAuth Magic Links Guide - Details on magic links and one-time code customization, including TTL configuration Passwordless API - Complete API reference for building custom passwordless flows Start Passwordless Login API - API to generate a passwordless code Complete Passwordless Login API - API to complete the passwordless login Tenant Configuration - Tenant-level external identifier settings including passwordless login TTL
    • F

      Solved How to customize root path and 404 pages to redirect to application login?

      Frequently Asked Questions (FAQ)
      • themes cloud customization redirect tenant • • FASupportBot
      2
      0
      Votes
      2
      Posts
      392
      Views

      F

      FusionAuth supports customization for some of these scenarios through themes, but not all:

      1. Root Path Customization

      This is possible. The Index page can be customized through your FusionAuth theme. You can add a redirect (for example, using JavaScript or a meta refresh tag) to send users to your application's login page.

      Important: When FusionAuth can't identify the tenant (including when browsing to / without client_id or tenantId parameters), it uses the default tenant. To theme the root page:

      Create a copy of the built-in theme — the default theme is immutable because it ships with FusionAuth Edit the index template in your copy to include your redirect (using JavaScript like window.location.href = "https://yourapp.com/login" or HTML meta refresh) Apply this theme to ALL tenants, including the default tenant Test with tenant specified — try the root URL with tenantId or client_id to confirm your edited theme renders

      See the Advanced Themes troubleshooting guide for more details on theme issues.

      Related: GitHub Issue #378

      2. OAuth Error Handling

      This is also possible. The OAuth error page can be customized in your theme, so you can implement the same redirect approach for customers who saved stale or broken login links. The OAuth error template is available for customization and you can add JavaScript or meta refresh redirects to handle these scenarios.

      Note that OAuth errors can also be returned as redirect parameters to your application's callback URL (depending on the OAuth flow), which allows your application to handle errors directly rather than showing the FusionAuth-hosted error page.

      3. 404 Pages for Invalid URLs

      This is NOT currently customizable. The 404 page cannot be customized, including on Cloud deployments. Requests to invalid paths (like /whatever) will show the default error page. This is a known limitation tracked in GitHub Issue #404, which requests additional themed error pages (including 404 and 500 pages).

      Summary

      You can handle root path and OAuth error redirects through theme customization by adding JavaScript redirects to the index and OAuth error templates. However, true 404 pages remain uncustomizable. CloudFront configuration is not exposed to customers on cloud deployments, so there's no workaround at that layer.

      Related Documentation Advanced Themes Documentation - Complete guide to customizing FusionAuth themes Theme Templates - Full list of available templates including Index and OAuth error Theme Template Variables - Variables available in each template Index Template Variables - Specific to the root page OAuth Error Template Variables - Specific to OAuth error page OAuth Error API Documentation - How OAuth errors are returned Default Tenant Configuration - Understanding the default tenant
    • F

      Solved Is there a Helm chart release for FusionAuth 1.53.4?

      Frequently Asked Questions (FAQ)
      • helm kubernetes deployment upgrade docker • • FASupportBot
      2
      0
      Votes
      2
      Posts
      488
      Views

      F

      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
    • F

      Solved Getting HTTP 429 rate limit errors during performance testing in FusionAuth Cloud

      Frequently Asked Questions (FAQ)
      • fusionauth cloud rate-limiting 429-error performance • • FASupportBot
      2
      0
      Votes
      2
      Posts
      347
      Views

      F

      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)
    • F

      Solved FreeMarker error: postMethod variable null in registration verify template

      Frequently Asked Questions (FAQ)
      • freemarker templates themes registration verification • • FASupportBot
      2
      0
      Votes
      2
      Posts
      306
      Views

      F

      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