It's so easy to mix up those IDs when you're moving between FusionAuth and the Google console! It’s definitely one of those things that’s right under your nose but impossible to see until someone points it out. Glad to hear you got the callback working - that 'invalid_client' error can be a real headache when everything else looks correct.

Because advanced themes are so customizable, they can be hard to upgrade. Here's some ways to make it easier.

When you create a new theme, start from the default version. Commit it to git before you change anything. Use the FusionAuth CLI to download/upload your theme during development and CI/CD. When a new theme comes out, clone or pull the latest from the theme history repo. Run this command to see what has changed: git format-patch 1.61.0..1.64.1 --stdout > update-themes.patch (this shows the changes between 1.61.0 and 1.64.1; adjust as needed for your installed version and the target version). Go to your theme git repo and apply the changes: git am --3way update-themes.patch which will attempt to automatically merge the changes. If there are conflicts, you can resolve them manually and then run git am --continue.

You can also use a 3 way diffing tool like diff3 or kdiff3 to visualize the changes.

These upgrade notes also provide detailed human friendly instructions on the changes.

I've found that setting the mobile number as the loginId is the most reliable way to handle this right now. You can just tweak the theme labels to say 'Mobile Number' instead of 'Username' so it's clear to the users. It’s a bit of a manual setup for the SMS verification part via the API, but it gets the job done without waiting for a native feature update.

There are a couple different scenarios where a login record could have a blank application Id. Usually it is #1 or #2. It occurs in scenarios where the user can have a JWT/access token that does not have the application Id in it.

If a user is not registered for the Application they are logging into FusionAuth makes a login record when a user is created since FA makes a JWT upon user creation If you use the Login API, you can log in without an App ID because you don't have to provide an application on the API call.

@hvfa Apologies for being a bit AWOL. I hope for things to slow down and be able to take a look at this a little more closely next week.

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?

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