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.
After upgrading FusionAuth from 1.55.x to 1.69.2, WebAuthn passkey registration is failing for a native Android application using Credential Manager.
reauthenticationdashboard.example.com)When completing registration via POST /api/webauthn/register/complete, FusionAuth returns HTTP 400:
{
"statusCode": 400,
"exception": {
"fieldErrors": {
"origin": [
{
"code": "[invalid]origin",
"message": "The [origin] property is not valid. The provided value must match the value returned by the authenticator. Expected [android:apk-key-hash:<certificate-hash>] but found [dashboard.example.com]."
}
]
}
}
}
The Android Credential Manager produces an origin in the clientDataJSON with the format:
android:apk-key-hash:<base64url-sha256-of-signing-certificate>
This is the standard Android format and cannot be modified by the application. FusionAuth 1.69.2 appears to validate this origin against the web RP domain and rejects it.
Before 1.69.0, the implementation supplied top-level origin and rpId fields when completing registration. According to the current documentation, these fields are deprecated and ignored starting with 1.69.0. The new implementation now passes only:
await fusionAuthClient.completeWebAuthnRegistration({
userId,
credential,
});
FusionAuth now reads the origin directly from the signed clientDataJSON and validates it strictly. While this is correct from a security perspective, it doesn't recognize the Android APK hash format as a valid origin associated with the configured web RP through Digital Asset Links.
android:apk-key-hash:<certificate-hash> format?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 tokenmetaData.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.
auth_time on JWTs vs Refresh TokensNote 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.
auth_time is officially documented as a JWT claimWhen querying the refresh token endpoint GET /api/jwt/refresh?userId={userId}, some refresh tokens include a data sub-object under metaData containing fields like auth_time and authentication_type.
This metadata appears to be present for the following authentication types:
However, when users authenticate using MFA + PASSWORD, the data sub-object is missing from the refresh token metadata.
Is this data object (specifically auth_time and authentication_type) something that can be reliably used across all authentication flows in current and future versions of FusionAuth? Or is its presence inconsistent and not intended as a stable API feature?
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.
When viewing deployments at account.fusionauth.io/account/deployment, the sort order appears inconsistent or random.
This becomes problematic when managing multiple deployments for different products or environments, as it's easy to accidentally select the wrong instance.
Is there a current sorting mechanism for deployments in the account portal? It would be helpful to have deployments sorted alphabetically by name or URL to prevent accidental misclicks when working with multiple instances.
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.
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.
To retrieve the specific outbound IP addresses for your deployment (e.g., to allowlist them with your SMTP provider):
Once assigned, these IP addresses will remain static and won't change during upgrades, restarts, or normal operations.
If you have both production and development environments:
We're configuring email delivery for our FusionAuth Cloud deployments, and our email service provider requires us to allowlist the IP addresses of any client connecting to its SMTP server.
Could you please provide the outbound (egress) IP address(es) used by our hosted instances?
A few related questions:
The behavior you're experiencing is likely related to the SSO Session Timeout setting in your Tenant configuration.
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.
Navigate to:
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.
The new timeout will apply to all new SSO sessions created after the configuration change.
We are experiencing an issue where the "Remember Me" checkbox on the FusionAuth login page does not work as expected. Users are consistently logged out after approximately one hour, regardless of whether they check the "Remember Me" option.
Environment:
Observed behavior:
What we've tried:
Is there a configuration setting or known issue that would cause FusionAuth to expire user sessions after one hour regardless of the Remember Me selection? How can we keep users logged in for longer periods when they've opted to be remembered?
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.
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:
SendNotifyTextMessage with the code as a template variableYou 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.
I want to enable SMS-based MFA in FusionAuth using AWS SNS Notify as the delivery mechanism. Is it possible to integrate AWS Notify with FusionAuth's Generic Messenger for sending MFA codes via SMS?
I'm aware that FusionAuth's Generic Messenger can POST to HTTP endpoints, but I'm not sure if it can directly integrate with AWS Notify's API requirements.
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).
You can determine token usage by checking the lastLoginInstant field on user registrations:
GET /api/user/registration/{userId}/{applicationId}) or search for users with tokensauthenticationToken, check the lastLoginInstant against your time windows (30 days, 90 days, 1 year)lastLoginInstant falls within your time window for any user, someone authenticated to that application during that periodHere'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.
authenticationToken and lastLoginInstantauthenticationType)authenticationType fieldAPPLICATION_TOKEN, PASSWORD, and othersWe have authentication tokens enabled for some applications in FusionAuth, and we want to determine if these tokens have actually been used for authentication in the last 30/90/365 days before disabling the feature.
We have approximately 225 users with authentication tokens assigned to their registrations. We can identify which users have tokens using an Elasticsearch query:
{
"bool": {
"must": [
{
"nested": {
"path": "registrations",
"query": {
"exists": {
"field": "registrations.authenticationToken"
}
}
}
}
]
}
}
However, we need to confirm whether these tokens have been actively used for authentication. Is there a way to audit authentication token usage through login records or other mechanisms in FusionAuth?
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.
Users are frequently landing on FusionAuth's 404 error page. Is there a way to customize the 404 page via themes to automatically redirect users to another page, or what are the recommended approaches to handle this situation?
This issue is related to Gmail's safe-links protection feature, which scans links in emails for security purposes.
When Gmail scans the password reset button/link, it fires two GET requests to the /password/change endpoint:
Each request triggers the MFA code generation, resulting in two codes being sent.
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:
/confirmation-required) into your theme to benefit from this feature. Without it, the protection doesn't work.state parameter is being mangled in a custom theme, causing unexpected behaviorAdd 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)
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.
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).
We are experiencing an issue where users receive two separate MFA codes when initiating a password reset flow.
Behavior observed:
Additional findings:
What could be causing this duplicate MFA code behavior, and how can it be resolved while maintaining a custom theme?
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.
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.
We are cleaning up an old development instance and deleting a tenant that was cloned from production. After clicking delete, the UI shows "Deleting..." but provides no progress indicator.
Is there any way to track the deletion progress or estimate how long it might take? The tenant contains a significant number of users (hundreds of thousands) from the production clone.