@elliotdickison I'd probably try with two Identity Providers configurations in FusionAuth both pointing to the same remote IDP.
One can have screen_hint=abc on the authorization URL and the other can have screen_hint=def, but both will have all the other parameters the same.
Then you can use an idp_hint on your create or login buttons.
I think that will work, but please let us know.
@elliotdickison Thanks for the feedback.
I'd love to chat a bit more to understand the problem.
Will send you an email.
Because advanced themes are so customizable, they can be hard to upgrade. Here's some ways to make it easier.
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).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 am using advanced themes and wanted to know how to find out what had changed in the themed pages when a new release happens.
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.
We have a user who has logged in repeatedly, but the application is blank.
https://fusionauth.io/docs/apis/login#search-login-records doesn't mention anything about this.
What gives?
I think the way I'd approach this is:
At cutover time:
I get that is an additional complexity, but hopefully that helps.
I have a large number of users. I want to import them into FusionAuth with their password hashes and the accompanying data like the factor.
But my cutover is going to be slow, so I expect some percentage of people to change their password hashes after the import.
So I'd like synchronize any password hashes that changed in the meantime, and then roll out FusionAuth.
I can't re-import password hashes for an existing user, and the User API doesn't let me update passwords hashes, per this closed issue: https://github.com/FusionAuth/fusionauth-issues/issues/348
What would you recommend?
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:
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.
I have an application using FusionAuth, and I want to prompt my end users to set up passkeys. Having this authentication method will improve their security and ease their future logins.
I know I can enable passkeys for FusionAuth using the community edition license, but how can I add a prompt in my application code/UI to have them set it up?
@brad sounds super frustrating.
I'll send you a message.
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:
What claims should I check when using google as an identity provider when I'm interested in making sure it is a google workspace account?
We have a docs MCP server.
This lets your MCP compatible IDE or client ask questions of all the FusionAuth docs, YouTube videos, Terraform provider, OpenAPI spec and more.
More details: https://fusionauth.io/docs/get-started/download-and-install/development/docs-mcp-server
Note that this functionality (logging in with a phone number) was delivered in 1.59.
More details here: https://fusionauth.io/blog/announcing-fusionauth-1-59
Hi FusionAuth community,
We just released a preview MCP server that allows you to control a FusionAuth instance from within any MCP client (Cursor, Claude Desktop, any agent that uses MCP, etc).
You can see the announcement blog post here: https://fusionauth.io/blog/fusionauth-mcp-server
And the GitHub repo, which includes installation instructions, is here: https://github.com/FusionAuth/fusionauth-mcp-api/
We'd love your feedback; feel free to leave it here.
Just an FYI, as of 1.59.0, phone number verification is now fully supported in FusionAuth.
Read more here: https://fusionauth.io/docs/lifecycle/manage-users/verification/gate-accounts-until-user-phone-verified
@atakan @theogravity-sb Seems like two different issues here.
@theogravity-sb is talking about attackers using the Google identity provider to create accounts with malicious names. @atakan is talking about attackers using self-service registration to create accounts with malicious names. They seem related but not identical. When you are allowing people to create their own identity and/or delegate to another source of identity, you decrease friction but give up some control.
The bad news is that FusionAuth has nothing out of the box to stop this behavior.
The good news is that you can build an integration to stop it. There are email verification services that give you a risk factor for email addresses and you can check that before you allow for registration or login.
Here's a blog post I wrote about leveraging a third-party service to check the validity of emails provided during registration. This post uses a self-service registration validation lambda, but for the Google identity provider use case, you could use the login validation lambda and perform the same type of check.
While I used Fideo because it had a good API and I had a connection there, I have not done an extensive survey of the landscape of email verification services, so cannot recommend any particular service.
FYI, this was fixed in 1.60.0, per the release notes.
In version 1.59.0 the password is now optional when creating or updating a user.
When returning from a third-party login, a user may be prompted to complete registration by entering a password when self-service is enabled and is configured to require a password.
This was unintended and has been corrected.
https://fusionauth.io/docs/release-notes/
Tracking issue: https://github.com/FusionAuth/fusionauth-issues/issues/3159