Unfortunately, lambdas won't help here. FusionAuth never exposes the password anywhere lambda code can access it, so you can't write a lambda that validates complexity.

You do have several other options, each with tradeoffs:

Low complexity for everyone, with MFA for franchise managers. Configure the tenant with low complexity rules and require MFA for the franchise manager group using the MFA lambda. The MFA lambda can be combined with most of the other options below.

Low complexity for everyone, with an IdP for franchise managers. Add an identity provider pointing to a different FusionAuth instance/tenant or a corporate directory, and have franchise managers authenticate there.

The FusionAuth instance can have more complex password requirements. Add a Login Validation lambda that denies login for users in the franchise manager group unless they authenticated through that IdP. Modify the theme to hide the IdP button on the normal login page. Pass an idp_hint on the authorization URL for everyone in the franchise manager group.

Passwordless for restaurant staff. Let restaurant staff log in without a password and set higher complexity rules at the tenant level for everyone else.

Two tenants with separate applications. Create tenant A (low complexity) and tenant B (high complexity). Have the restaurant staff application use tenant A's ID and the franchise manager application use tenant B's ID. You could also use a universal application to represent the application.

Two tenants with a connector. Again, tenant A is low complexity and tenant B is high complexity.

Set up a connector from tenant B to tenant A, with MFA lambda rules in tenant B for franchise managers. Configure the connector to not migrate users. Have all users log in to the application in tenant B, which checks tenant A for restaurant staff.

All of these will work, but they have tradeoffs. Some may increase your MAU count, and some may add latency.

Why not per-application password rules?

As an aside, I don't expect FusionAuth to ever support different password rules per application, because it would lead to confusing user experiences:

If the staff app requires 10 characters and the manager app requires 15, and a user registers in the staff app, what happens if/when they log in to the manager app? Do we deny the login? Force a password change? If the staff app requires 10 to 20 characters and the manager app requires 25 to 35, no single password can satisfy both. Would a user have to change their password every time they switch between the two apps? Can you migrate users between applications?

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.

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

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

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

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

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.

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

Hi @david-kircheis,

The cross-platform authenticator passkey functionality is not available for the licensed community edition, only the platform passkey functionality.

The options I see for your use case are:

talk to sales about an enterprise license, if it fits your business model. We do offer non-profit discounts in certain circumstances. use platform authenticators with all their limits move to a different identity provider

While we'd love to have FusionAuth used by everyone, we can't offer all features to every plan level. We recognize this limit means FusionAuth isn't the right solution for every authentication problem.

I appreciate you using FusionAuth now and hope it remains helpful to you.

@bryan-robinson

I'm getting the 4503 even though I'm running the caller and FusionAuth on localhost for dev testing purposes. The caller is on localhost:8080 and FA is on localhost:9011.

According to the documentation for app/refresh, this should work.

Any ideas?