Is it possible to set all users to have the passwordChangeRequired status set to true by default, so they are forced to reset their password upon their first login? Additionally, can we set a default password format as company{username}? For example, a user with the username 1234 would have the default password company1234.

We’re integrating FusionAuth with our system and want to verify users’ phone numbers during registration, but we’re not ready to enable two-factor authentication (2FA). Is there a recommended way to implement phone number verification via SMS during registration without enabling 2FA? Ideally, we’d like users to enter their phone number and verify it before completing the registration process.

Our FusionAuth instance only lists 11 Lambdas by default, and JWT Populate is not one of them. How can we create a JWT Populate Lambda?

Does FusionAuth provide an API to import roles for an application?

We are using the /api/user/forgot-password API for password resets, with sendForgotPasswordEmail set to false since we send our own email. However, users are now receiving two emails: our custom email and a password reset email from FusionAuth using our template. This issue occurs only in our pre-live and production environments, not in the local Dockerized version. What could be causing this?

This is indeed unusual, especially since the issue appears to affect only a single user and device, which makes a FusionAuth configuration issue unlikely.

A few things to check and try:

• Open in External Browser
• Ask the user to tap the three-dot menu (if available) in the webview and choose “Open in Chrome” or their default browser.
• If the page loads correctly there, the issue is likely related to the embedded webview rather than FusionAuth itself.

WebView / Browser-Specific Issues

Some Android devices (including certain Xiaomi models) ship with custom WebView implementations or aggressive privacy/security settings that can interfere with embedded web content.

Ensure the device has the latest Android System WebView and browser updates installed.

Domain / CNAME Edge Cases

There have been rare cases where mobile browsers or webviews behave unexpectedly if the domain includes characters such as underscores (_) or dashes (-) in certain positions.

While this typically results in explicit errors (like “Address not found”), it’s still worth reviewing your domain and CNAME setup—especially since you’re self-hosting.

Given that the login works for the same user on other devices, this is most likely a device- or WebView-specific issue rather than a problem with FusionAuth itself. If opening the login page in a full browser works, that should help narrow the root cause to the embedded webview implementation on that device.

We received a report from a customer who is unable to log in to our mobile application. The app uses a standard embedded webview that loads the FusionAuth-hosted login page, a flow that has been in place and working reliably for all users until now.

In this specific case, the webview appears to be completely blank and does not load the login page at all.

Additional context:

Device: Xiaomi Redmi Note 13
OS: Android

Clearing app data/cache did not resolve the issue

Logging in as the same user works correctly on other devices

Have you encountered a similar issue before, or do you have any guidance on what could cause this behavior?

You’re correct: FusionAuth’s Lambda environment does not provide access to external libraries (including AWS SDKs or SigV4 helpers), and there is no secure secrets store available to Lambdas. That means if you need AWS SigV4 signing from inside a Lambda, you would have to implement the signing logic yourself and embed any required credentials directly in the Lambda code—this is generally not considered secure.

Also, if you are using FusionAuth Cloud, you cannot place Lambdas into your private network (for example, the same VPC/network as your API Gateway), so that option isn’t available in hosted deployments.

If you need this capability, the recommended approach is typically to move the signing and secret handling into a system you control (for example, a backend service that FusionAuth calls), rather than performing SigV4 signing directly in a FusionAuth Lambda.

Related issue tracking:
https://github.com/fusionauth/fusionauth-issues/issues/1629

We need a FusionAuth Lambda to call a private Amazon API Gateway endpoint. The API is protected using AWS SigV4 request signing (credentials + access tokens) and also restricts access via IP allowlisting.

In our Lambda implementation, it looks like we don’t have access to standard crypto/request libraries (for example, AWS SDK signing helpers). We’re trying to replicate the following Ruby logic:

RestClient.get("#{ENV['FKO_API_URL']}/#{cvr}/#{fka_id}", signature.headers)

def signer
  Aws::Sigv4::Signer.new(
    service: "execute-api",
    region: "eu-central-1",
    access_key_id: ENV["FKO_API_ACCESS_KEY_ID"],
    secret_access_key: ENV["FKO_API_SECRET_ACCESS_KEY"]
  )
end

def signature
  signer.sign_request(
    http_method: "GET",
    url: "#{ENV['FKO_API_URL']}/#{cvr}/#{fka_id}",
    headers: { "Content-Type" => "application/json" }
  )
end

Questions:

Can FusionAuth Lambdas access crypto or request libraries (for example, AWS signing libraries) to generate SigV4 signatures?

If not, is it possible to run FusionAuth Lambdas within the same private network as our API Gateway?

If neither is possible, does that mean we must implement SigV4 signing ourselves (and embed credentials in the Lambda)? Any examples would help.

Reference: https://fusionauth.io/docs/extend/code/lambdas/lambda-remote-api-calls

This is a known bug, and it looks like the underlying issue has already been identified and fixed. The fix will be included in the next FusionAuth release.

I’m trying to configure a webhook that determines whether a user can self-service register for an application. This worked in my local FusionAuth instance, but I’m running into an issue in FusionAuth Cloud.

In Cloud (v1.59.0), I cannot change the transaction setting for events like:

• user.registration.create
• user.registration.delete
• user.registration.update
• user.registration.verified
• user.update

In my local instance (v1.57.1), I was able to set the transaction behavior (for example, requiring all or some webhooks to succeed before continuing the transaction). In Cloud, those transaction options are greyed out.

Why are these transaction settings disabled in FusionAuth Cloud?

How can I re-enable the ability to configure them?

Is this related to the version difference (1.59.0 Cloud vs 1.57.1 local), or something else?

There are a couple of overlapping layers here.

1. Access tokens aren’t revocable by default
   Access tokens (JWTs) are self-contained. Once issued, they remain valid until they expire unless you implement a custom revocation strategy (such as token blacklisting). FusionAuth covers one approach here:
   https://fusionauth.io/articles/tokens/revoking-jwts
   So if your access token lifetime is 600 seconds, a disabled user could continue to access APIs until that token expires (up to ~10 minutes) unless you add an additional revocation layer.

2. FusionAuth sessions are typically independent from the IdP
   Once the upstream IdP authenticates the user, FusionAuth generally maintains its own session state. If a user is disabled in the upstream IdP, that does not automatically invalidate FusionAuth sessions or prevent refresh token usage.
   So yes, depending on your implementation, a user can potentially continue to operate in FusionAuth even if they are disabled upstream, until you either:

   • expire/stop honoring their tokens, or
   • remove/disable the user in FusionAuth, or
   • enforce additional checks at login/session refresh time.

3. Options to meet “disabled within 300 seconds” for one customer
   If you need disablement to take effect quickly without shortening sessions for everyone, you generally need an integration that pushes the disablement signal into FusionAuth (or into your resource servers).

   A. SCIM (best fit when the customer maps cleanly to a tenant)
   If your customer can be logically isolated (e.g., “customer A users live in tenant A”), SCIM is a strong option. The customer’s IdP can provision/deprovision users into FusionAuth, and a disable/delete action can remove their FusionAuth access (including sessions). This is the cleanest approach when tenant segmentation is possible.

   B. Event-driven deprovisioning (IdP → your service → FusionAuth API)
   If the customer’s IdP can emit events (user disabled/deprovisioned), you can build a lightweight integration that:

   • receives the IdP event, then
   • disables or deletes the corresponding user in FusionAuth via API.

   Once the user is disabled/deleted in FusionAuth, they won’t be able to continue normal authentication flows.

   C. Token revocation strategy (resource server enforcement)
   If the requirement is “deny access within 300 seconds,” the most deterministic way is to enforce it at the API/resource-server layer by:

   • using short access-token lifetimes (<= 300 seconds), and/or
   • adding token blacklisting / introspection-style checks in your APIs.

   This avoids relying on refresh token expiration to enforce disablement.

About limiting refresh token lifetime per customer

A reconcile lambda can help with user provisioning and claims, but it won’t reliably solve the core issue of existing sessions and refresh tokens already issued. There isn’t a simple “per-customer refresh token TTL override” you can apply after the fact without an architectural approach like the ones above.

We have a customer with strict session-lifetime requirements and I’m trying to understand the best way to implement them in FusionAuth.

This customer authenticates through their own IdP, which we’ve configured as an Identity Provider in FusionAuth. In our tenant, we’ve configured:

• Access token (JWT) duration: 600 seconds
• Refresh token duration: 960 minutes

These settings work well for users who log in directly through FusionAuth because they can stay signed in for a long time without re-authenticating.

However, this customer requires that if a user is disabled, they must be denied access to our application within 300 seconds or less.

My understanding is that FusionAuth will continue to honor the user’s existing session (via refresh tokens) for up to the full refresh token lifetime, and the user won’t be forced back to the customer’s IdP until the refresh token expires.

1. Is that understanding correct?
2. If so, what options do we have to meet this customer’s requirement without forcing all users to re-authenticate every few minutes?
3. Can we limit refresh token lifetime for only this customer, possibly via a reconcile lambda or another mechanism?

At this time, FusionAuth does not support changing WantAssertionsSigned to true in the generated SAML metadata. This value is hard-coded and cannot be modified through IdP configuration or other settings.

From a practical standpoint, this should not impact security or standards compliance. FusionAuth signs the entire SAML response using the verification key configured in the IdP. Since the assertion is part of the signed response, signing the assertion itself would be redundant and is not required by the SAML specification.

If your client strictly requires WantAssertionsSigned="true" due to a non-standard or legacy implementation, this would need to be addressed on the Service Provider side, as FusionAuth cannot currently emit metadata with that value set to true.

We have a client requirement for our SAML metadata to specify WantAssertionsSigned="true".
We’ve configured a verification key in the Identity Provider (IdP) settings, but when we generate the metadata, the value still appears as WantAssertionsSigned="false".
Is there a way to configure FusionAuth to set this value to true in the generated metadata?