@jefferson-piscos, the debug enabled is under the OAuth tab. Go ahead and enable that and check the logs.

Also it is a little weird that you are redirected to a consent screen. Do you have any consents configured? You can go to Settings -> Consents in the Admin UI.

Then you can check the user and see if you have any set for the user you are testing.

Hopefully that will clear it up and you will be good to go. If not, let's see what those logs say.

@jefferson-piscos There are a few things that may be going on. Where are you you expecting to redirect to after successful login? Can you tell if that page is being hit or is it redirecting back to the login page because that is the page you set it to? Anything you can safely share about the application configuration in FusionAuth or code for your redirect page could be helpful.

It terms of tips for debugging, you can turn on "Debug Enabled" for the identity provider and then check the Event Log after you try to log in. Let us know if that yields any useful information.

@michaelginn529 What do you have your "Logout behavior" set to for the application? Any other specific configuration you can share would help as well.

@haziqt Sounds like FusionAuth is up and working except reporting the wrong IP address of the user on login. You may want to consider opening a issue.

@raymondcamden Ha, gald you got it working. Generally, the quickstarts come with a docker file that you can just run docker compose against and it will get you the instance. That instance would be configured to work with the sample code for that quickstart. The application and uses would be created and things like that. If you have it working the way you want, awesome. If you run into other issues, please just let us know.

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.

@raymondcamden Are you using the Quickstart app? If so, you need to use the Docker instance specified in the app. If you just spin up a brand new instance of FusionAuth, the sample app does not exists and that is likely why you are getting the error message. Try using the Docker instance in the Quickstart and you should be fine. Let me know how it goes.

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.

Overview Table

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 Instance

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.

Cruise Ship FusionAuth With QR Codes

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.

Steps:

1. Copy user profile data to the cruise ship instance using the User API.
2. Create a QR code that is associated with each user and add it to the ticket (or provide it separately). The user can then log in by scanning their phone.
3. The QR code should include the user's login Id. Implement using the passwordless API, starting the passwordless login with the users id, and completing the login by catching the code and using the complete login API call.
4. Mark the accounts as 'on-cruise' in the user.data field. By doing this, you can clearly differentiate between the users on the cruise and anyone else in your CIAM system. This makes it easier to merge their profile data after the cruise.
5. Set up a webhook to disable any updates to these user accounts in the cloud FusionAuth instance while on the cruise. You can do this by setting up a transactional webhook on user.update that fails when the user being updated has the 'on-cruise' attribute set.
6. When on the ship, users can log in with these credentials and access applications, as well as update their profiles.
7. After the cruise is done, compare the profile update timestamps for all users in the cruise instance with the same account on the cloud instance.
8. If the update timestamps do not match, update the cloud instance with the new profile data. Do not move the password hashes.
9. Remove the 'on-cruise' attribute from users in the cloud instance.

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.

Cruise Ship FusionAuth With Existing Passwords

Here you are migrating the source of truth for these users to the cruise ship instance, including passwords, and then syncing them back.

Steps:

1. Build an import script by reading the password hashes and other password data from the cloud instance for the users who are going on the cruise.
   • This requires direct database access to the cloud instance.
2. Import the users using the Import API to the cruise ship instance.
3. Mark the accounts as 'on-cruise' in the user.data field.
   • By doing this, you can clearly differentiate between the users on the cruise and anyone else in your CIAM system. This makes it easier to merge their profile and credential data after the cruise.
4. Set up a webhook to disable any updates to these user accounts in the cloud FusionAuth instance while on the cruise. Do this by setting up a transactional webhook on user.update that fails when the user being updated has the 'on-cruise' attribute set.
5. When on the ship, users can log in with their normal credentials and access applications, as well as update their profiles and password.
6. After the cruise is done, compare the update timestamps for all users in the cruise instance with the same account on the cloud instance.
7. If the update timestamps do not match, build an import file with the profile data and updated credentials.
8. Read the credentials from the cruise ship instance database.
9. Remove the 'on-cruise' attribute from users in the cloud instance.
10. Delete the users' accounts in the cloud instance and import the user data from the cruise ship generated file.

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.

Cruise Ship FusionAuth With Existing Passwords And Changes Allowed to Cloud FusionAuth

Here you are migrating these users to the cruise ship instance, including passwords, and then merging them back.

Steps:

1. Build an import script by reading the password hashes and other password data from the cloud instance for the users who are going on the cruise.
   • This requires direct database access to the cloud instance.
2. Import the users using the Import API to the cruise ship instance.
3. Mark the accounts as 'on-cruise' in the user.data field so that we'll know which users to merge.
4. When on the ship, users can log in with their normal credentials and access applications, as well as update their profiles and password. The same accounts can be updated in the cloud instance by users or automated processes on land.
5. After the cruise is done, compare the update timestamps for all users in the cruise instance with the same account on the cloud instance.
6. If the update timestamps do not match, build an import file with the profile data and updated credentials. For the latter, you'll need to read from the cruise ship database.
7. Prepare to merge the data from the cruise ship and cloud instances.
8. Read all accounts with the 'on-cruise' from the cloud instance with an update date later than the start of the cruise.
9. Find all the users on the cruise ships with an update date later than the start of the cruise.
10. For each account, see what changes were made:
    • If a cloud instance did not change and the cruise ship instance did not change, remove the 'on-cruise' data marker and do nothing else.
    • If a cloud instance changed and the cruise ship instance did not, remove the 'on-cruise' data marker and do nothing else.
    • If a cruise ship instance changed and the cloud instance did not, prepare an import entry from the cruise ship instance for this user. Delete the cloud instance account and then import the cruise ship instance account.
    • If a cruise ship instance changed and the cloud instance did as well, prepare an import entry from the merged cruise ship and cloud instances. How you do this is business dependent. There may be user profile data that should be merged, and other data that might belong to either the cruise ship instance or cloud instance. The most recent password, wherever it lives, is the one that you should use for the import.
11. When the merge is complete, write an import entry to a file. Remove the 'on-cruise' attribute at the same time.
12. When all accounts have been merged successfully, delete the cloud instance account and then import the merged account.

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.

Other Considerations

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