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.

@mark-robustelli thanks Mark.

All domains will be sub-domains of the main domain name, but for this staging system, we are using 2026.domain.com and 2026-tenant1.domain.com, 2026-tenant2 etc.

Logins work successfully without the idphint on a per tenant basis but we want all tenants to use the common master tenant (via SSO) as the login, because many users will be members across multiple tenants and their data can be common across tenants.

The auth server uses auth.domain.com

We have the master tenant and sub tenants in FusionAuth. We have the master application and sub-tenant applications for each tenant.
A tenant application has an authorized redirect like 2026-tenant1.domain.com/callback and currently no request origin (I have tried adding this for sub-tenant and master tenant together). I've tried adding the sub-tenants as authorized origins on the master tenant.

There's nothing extra configured on the FusionAuth tenants.

Under settings, Identity Providers, we have an OIDC provider pointing back to the master app in the master tenant. We do see the button to login with master tenant on a sub-tenant (if no idphint is set).

All sub-tenant applications are enabled for this provider (with create reg), I also have the sub-tenants added in this IP and have tried without. Managed domains is blank. Not using the POST method.

Auth endpoints have been manually set (because FusionAuth couldn't self-discover?!) like so:
https://auth.domain.com/oauth2/authorize,
https://auth.domain.com/oauth2/token,
https://auth.domain.com/oauth2/userinfo

There's no groups configured.

Hosting wise, FusionAuth is a Docker container on the same server with the main app and sub-tenants behind a Traefik 2 proxy which is also behind Cloudflare and each site has its own LetsEncrypt SSL cert via Traefik.

Direct login to the master tenant is successful but not via a sub-tenant.

Grok suggests it's a CORS issue. My filter was not enabled. I also tried enabled (current) and allowed all methods with (and without) wildcard origins.

As mentioned, the login is recorded on FusionAuth, it just seems to fail on the callback process via master..

The master login URL when called via a sub-tenant shows the master tenant as the callback URL. I've tried adding the sub-tenant callback as authorised in the master tenant.

I think that's everything..

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!

@james-hudson You may want to check out this blog post. Hopefully that can help.

@scottw Hopefully, I can get a little time over the next couple of days and see if I can duplicate it. I will let you know if I find anything. Anyone else seeing his behavior?

@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.

@david-cuen Thanks for your patience and dedication to seeing this through. It would help a ton if you could find something reproducible. Let me know what you find and I can continue to try it on this end.

@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?