I think the way I'd approach this is:

import all users into FusionAuth

At cutover time:

look at local database to see which password hashes had changed pull the user data from FusionAuth for each of these users delete the user re-import the user with the new password hash and the FusionAuth data, maintaining the same userId (if you provide the UUID, we'll use that)

I get that is an additional complexity, but hopefully that helps.

This is totally possible.

You want to start by understanding FusionAuth passkey setup and the normal flow.

Then, in your application, probably using one of the client libraries, you want to do the following for a user:

see if a user has a passkey set up, using the "retrieve a passkey" API. If this returns 0 passkeys, show the prompt. for the prompt, you have two options: use the API/client library to start the passkey registration process from within your application directly send them to the user management page to add a passkey (requires a paid license)

The right way to do the latter depends on your application needs (are you okay with a redirect) and whether or not you have at least a starter license.

For reporting on the number of users that have set up passkeys, unfortunately you have to query all your users and then pull the passkey data individually. There's no way to use the elasticsearch syntax to do the query as of yet. There's an open github issue to add that functionality.

@ralph Thanks for following up and sharing!

@rgros Do you have Debug enabled?

Screenshot 2026-02-18 at 10.43.14 AM.png

Then you should check your Event Log.

Screenshot 2026-02-18 at 10.44.20 AM.png

Let us know what you find.

@tim-clark Can you please point to the community discussion where this comes up? I could not find it in the issues.

@hemanth18pages raising the support ticket is the way to go for sure. It will be good to know if anyone else is experiencing this too.

@bernardo-munz Did you play with the SameSite setting?

@dan said in Error getting list application due to sql error (mysql):

@traperwaze said in Error getting list application due to sql error (mysql):

MariaDB server

I believe the issues is that we don't support MariaDB.

This is a known issue: https://github.com/FusionAuth/fusionauth-issues/issues/367 poki

Do you see the same issue with a supported version of MySQL or PostgreSQL?

Thanks for confirming. That lines up with what I’m seeing as well. We are indeed running MariaDB, and it looks like the JSON operator (->>) used in that query isn’t supported the same way in MariaDB, which would explain the syntax error.

We haven’t tested this yet on a supported database, but based on the linked issue and your comment, it does appear to be a MariaDB compatibility problem rather than a misconfiguration on our side. We’ll plan to test against a supported version of MySQL and/or PostgreSQL to confirm.

Appreciate you pointing us to the GitHub issue — that helps clarify things a lot.

@dalamenona We had the same error with Prometheus.
The following opened FusionAuth issue contains information about the topic

https://github.com/FusionAuth/fusionauth-issues/issues/3082

Best regards.

@simon-chrzanowski can you please share the code you using? (please be sure to hide anything sensitive like your API Key)

@dan said in Claims to check when using google as an idp for google workspace:

You should start by checking the relevant google documentation.

As of writing, this is what their doc says:

Using the email, email_verified and hd fields, you can determine if Google hosts and is authoritative for an email address. In the cases where Google is authoritative, the user is known to be the legitimate account owner, and you may skip password or other challenge methods.

Cases where Google is authoritative:

email has a @gmail.com suffix, this is a Gmail account. email_verified is true and hd is set, this is a Google Workspace account.

Users may register for Google Accounts without using Gmail or Google Workspace. When email does not contain a @gmail.com suffix and hd is absent, Google is not authoritative and password or other challenge methods are recommended to verify the user. email_verified can also be true as Google initially verified the user when the Google account was created, however ownership of the third party email account may have since changed.

So in this case, you want to check that hd is set as well as that email_verified is true.

With FusionAuth, you can check this using a reconcile lambda and looking at the id_token:

https://fusionauth.io/docs/extend/code/lambdas/google-reconcile https://fusionauth.io/docs/extend/code/lambdas/openid-connect-response-reconcile

Thank you from bringing this to light.

@alexandros-nafas , were you able to figure it out?

@johnmiller It looks like the issue is that the 'retrieve a user via JWT' functionality was removed in 1.60.0. (It appears the User API JWT authentication method was deprecated in version 1.50.0. An issue has been filed to remove it from the client libraries.

Thank you from bringing this to light.

@mark-robustelli Thanks, I think that's resolved it!

@Ruka , this seems like something that should be reported as an issue.

@patrick_ag Is this just when you are loading the page or are you trying to take some action?

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.

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

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.

There are a couple of overlapping layers here.

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.

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.

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.