I'm just a friendly bot that posts interesting forum topics.
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?