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
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
Yes.
A few options. Let's assume you have a FusionAuth instance hosted in your cloud (the cloud instance) and that you'll be running an instance on the cruise ship (the cruise ship instance). The cloud instance contains all user data. The cruise ship instance is going to be set up fresh for each cruise, with a copy of data from the cloud instance. It'll contain just the users on the cruise ship, and applications on the cruise ship will be set up to authenticate against it.
Option | Use When | Notes | Works With FusionAuth Cloud |
---|---|---|---|
Use The Cloud Instance | You have connectivity. Included for completeness. | Yes | |
Cruise Ship FusionAuth With QR Codes | You only want to let the user modify their profile, are okay with the risk of the QR code being stolen and the user being impersonated. | Need to use the API/SDKs to fully implement. | Yes |
Cruise Ship FusionAuth With Existing Passwords | You want the cruise ship instance to be the source of truth for users on the ship. | No | |
Cruise Ship FusionAuth With Existing Passwords And Changes Allowed to Cloud FusionAuth | If accounts of cruise ship users need to be modifiable by people on the cruise ship and on land. | Requires careful profile and credential merge logic. | No |
Use the cloud FusionAuth instance for all requests. This is the simplest solution, though it may be costly or lead to degraded functionality.
This is mentioned for completeness, but doesn't really address the core issue of missing or intermittent internet connectivity.
Here you are migrating the source of truth for these users to the cruise ship instance, excluding passwords, and then syncing the profile data back.
The main reason to choose this option is because it works with a FusionAuth Cloud hosted cloud instance, where you do not have access to the password hashes.
Security Warning: This is a security risk! Understand the security model of an account takeover in the cruise ship instance. If anyone else scans the QR code, they can get access to the user's account.
The benefit is simple merging of data. You also don't need access to the database of the cloud instance, because all the data you are merging is available via the API.
After successfully pushing the data to the cloud server, wipe the cruise ship FusionAuth instance.
Here you are migrating the source of truth for these users to the cruise ship instance, including passwords, and then syncing them back.
The benefit is simple merging back to the cloud instance, because only one instance accepts changes at a time. A user is either managed by the cloud instance or by the cruise ship instance.
Automated account recovery won't work, so plan to allow staff to reset passwords if needed.
After successfully pushing the data to the cloud server, wipe the cruise ship FusionAuth instance.
Here you are migrating these users to the cruise ship instance, including passwords, and then merging them back.
Automated account recovery won't work, so plan to allow staff to reset passwords if needed.
After successfully pushing the data to the cloud server, wipe the cruise ship FusionAuth instance.
If you are only allowing the user to change their profile data, you can move data without accessing the database. If users can change their passwords, you have to have access to the database to re-import them. (Or you can force a password reset.) The same applies to other secrets such as passkeys or TOTP secrets.
Options 1 and 2 work with FusionAuth Cloud hosted servers, but the other options do not because you don't have access to the database with FusionAuth Cloud.
If you allow a user to register on the cruise ship server, you will have to check for merge conflicts. If someone registered on the cruise ship, it is possible someone could have done the same on the cloud instance during the time of the cruise. Since you know all the cruise ship users, you can alternatively create accounts for everyone and disallow on ship registration.
When reading the password hashes, make sure you consult the schema for your version of FusionAuth, because the location of password hashes may change over time.
Account recovery is not available on the cruise ship, so make sure staff understands how to reset a user's password directly via the admin UI.
What is outlined above takes the final state of the user from the cruise ship and propagates it back the cloud instance. If you need to keep track of changes to the user on the cruise ship instance and replay them in order, use the webhook and event log to capture the events locally. Then replay them when the cruise ship docks using kafka.
Can I use FusionAuth in a distributed fashion when the internet is non-existent or intermittent? Like if I have a cruise ship, can I copy user data on to it to let them log into apps and possibly change profile or credentials and somehow get that back to a server on the mainland?
We have an open issue to make passkeys one of the supported MFA methods.
But you can perform a step up passkey challenge using the APIs or the SDKs by doing the following:
If someone doesn't have a passkey enabled, which you can check by calling the /api/webauthn?userId={userId} API, direct them to the self-service account management passkey management pages.
Here are the API docs for the webauthn API.
Can I do a step up authentication with WebAuthn/passkeys? I want to build this into my app for protecting some sensitive data.
As of 1.59.0 this is possible but it is slightly unintuitive how to do it. It’s entirely driven by the form being used. Here's how to do it:
You can also create a user directly via the API with no password.
This functionality is now present in FusionAuth as of 1.59.0.
https://github.com/FusionAuth/fusionauth-issues/issues/484 is the tracking issue.
Yes, I believe so.
It appears that connecting MitID to an application (also called an SP) requires utilizing an approved broker. A broker is essentially an OIDC connector.
Here is a list of official brokers: https://www.mitid.dk/en-gb/broker/current-brokers/.
We haven’t tested this, but based on reviewing Signicat’s OIDC documentation, the process seems fairly straightforward. They are one of the MitID brokers.
Does FusionAuth support MitID which is a national digital id for Denmark?
You can create two values for the FusionAuth url:
internalFusionAuthURL="http://fusionauth:9011"
externalFusionAuthURL="http://localhost:9011"
So basically whenever you are sending the redirect to the browser (pretty much just the authorize and logout URLs) you use externalFusionAuthURL which references localhost.
When you are communicating with FusionAuth from the application backend (the express app) you use the internalFusionAuthURL which references the docker domain name.
I tested that out and it seems to work fine.
Give that a try.
Hiya,
I want to run FusionAuth and the backend app in Docker, but run into an issue with this quickstart: https://github.com/FusionAuth/fusionauth-quickstart-javascript-express-web/
When I modify the complete-application/.env file to have the value for fusionAuthURL=http://localhost:9011
the token exchange fails (because the dockerized express app doesn't know how to get to FusionAuth).
When I set fusionAuthURL=http://fusionauth:9011
where fusionauth
is the internal docker network domain name of the FusionAuth server, the initial redirect fails, because my browser doesn't know about that domain (not being in Docker).
How can I fix this?
Worth re-emphasizing that this voids any warranty you might have from FusionAuth, per the license, exhibit A section 5.1.
You can't get support from FusionAuth if you modify the software.
Yes. You can use FusionAuth's OpenID Connect Identity Provider.
I did this a few weeks ago, so am writing these instructions from memory.
Prerequisites:
Steps:
https://<your instance>/oauth2/callback
Client ID (Consumer Key)
and Client Secret (Consumer Secret)
.Client ID (Consumer Key)
and Client Secret (Consumer Secret)
into the Client Id
and Client secret
fields, respectively.Discover Endpoints
. Manually configure the endpoints:
Authorization Endpoint
to https://api.login.yahoo.com/oauth2/request_auth
Token Endpoint
to https://api.login.yahoo.com/oauth2/get_token
Userinfo Endpoint
to https://api.login.yahoo.com/openid/v1/userinfo
Scope
to openid email profile
and any other scopes you might need. (I was unable to find an authoritative list, but here's info about the mail scopes.)Button text
and Button image
as needed.I'd like to off a "Login with Yahoo!" button. Can I use FusionAuth to do so?
This is due to non-ASCII characters in headers causing an issue in the FusionAuth parsing code. Cloudflare sends headers with non-ASCII characters (such as cf-region: São Paulo
) which triggers this issue.
This is a java-http bug that was fixed in 2024, and released in FusionAuth version 1.51.2.
So, two options:
We were using a FusionAuth cloud deployment directly but now want to use Cloudflare in front of it.
We are now seeing intermittent, infrequent 502 errors.
We see errors like this in the logs
2025-06-24 14:05:09.345 PM ERROR io.fusionauth.http.server.HTTPServerThread - An exception was thrown during processing
java.lang.IllegalArgumentException: Not a valid Unicode code point: 0xFFFFFFC3
How can we resolve this?
This is not available today without some glue code.
Currently our suggestion is to use Javascript on the Login page to jam the claim into a meta field that is shown on a Webhook payload, like jamming stuff into event.info.deviceDescription
.
Then you create user.login.success
webhook, making sure it is transactional. On login, the event is fired that off to your system and then you extract the claim off the event.info.deviceDescription
field and make a PATCH
call to FusionAuth. In that PATCH
call, you add this to a field on user.data.x
.
Then once that PATCH
is successful, the 200
response back to the user.login.success
event which completes the login and triggers the JWT populate lambda. That lambda extracts the claim off the user.data.x
field and puts it into the JWT.
It's not pretty but it is the only way to have this work for now. (For self-service registration you can use a custom hidden field, much easier.)
Relevant docs:
How can I add in custom claims in to the JWT based on a custom login field or other parameters on the login form?
I have a parameter/variable that can change between each login (like a device id) and want it to be in the access token.