I have added a further suggestion to the issue on the app repo.

https://github.com/FusionAuth/fusionauth-issues/issues/1250#issuecomment-859634082

@marcasellkhelaifi,

Glad that you got this figured out! Thanks for sharing!

Thanks,
Josh

@justinfox,

Awesome, glad that you got it working!

Thanks,
Josh

Thanks for the additional information @david-billings. We will have to see if we can do some additional testing to recreate.

Josh

@alex

I was out of the office last week, but am looking at this now.

I would say that you would be best served by checking the event logs. The logs that you have displayed here are from the main application and may not show as much debug information as the events logs do (when the debug toggle is enabled in the specific IdP and/or lambda).

Regarding your other questions, I was able to make an advanced registration form with both an email and username input. Since Google does not return a username, FusionAuth will send you to a complete registration page and ask for a username. The unique username policy set on the tenant will ensure no username collisions.

Then my_user_name becomes appended by the unique user name constraint set on the tenant
b8d46e80-596d-4e32-8252-65a7a75c2ab3-image.png

re:

The user can merge accounts (including all application-specific data) by requesting a merge. The requested-of account would receive an e-mail notification asking permission to merge, which would be valid for a short/customizable period of time.

We don't have this functionality exactly but have an approximation. On this user, notice the linked accounts tab. You can remove externally linked accounts here as an admin. Additionally, if you set create a pending link, as your linking strategy (instead of link on email), you can have your user login with google and associate that google UUID to an existing FusionAuth user (or create a new user).

I am not sure if this fully addresses what you are asking. My encouragement would be to review the documentation that we just released around linking IdP accounts, linking strategies, etc.
https://fusionauth.io/docs/v1/tech/identity-providers/

Here for any further clarification needed 🙂

Thanks,
Josh

dac8d112-09f0-41b0-9fa5-9d47bbf40c0a-image.png

Thanks,
Josh
FusionAuth

@chrissmueller328

There is some discussion of this (mostly focused on SAML, but OIDC is referenced and considered as well)

https://github.com/FusionAuth/fusionauth-issues/issues/566

I will review further and see if the team has any other thoughts.

Thanks,
Josh

@dan Thanks for the reply Dan, I'll go ahead and discuss this with my team before we go any further.

Just to double check, could the FusionAuth team revise this document's flow chart of the logout request if it's no longer correct? https://fusionauth.io/docs/v1/tech/guides/single-sign-on, or perhaps specify that the Logout request is specific to the FusionAuth app, not Pied Piper? Thanks.

e27f08e0-7665-46f9-a89f-f26637003a18-image.png

Bug filed here: https://github.com/FusionAuth/fusionauth-issues/issues/1740

A CLI tool for managing configuration can be super handy for those who love working from the terminal. There are definitely some robust APIs and terraform providers you've pointed out.

@epnyc Are you sure the "Client credentials JWT populate" is the type of lambda you want to create and not a "JWT populate" lambda?

If you are looking to assign a "JWT Populate" lambda, you need to go to Applications -> Your Application and select to the JWT tab and then select the lambda under the Lambda settings. (You will need to create a lambda of this type in Customizations -> Lambdas)

If you are looking to assign a "Client credentials JWT populate" lambda (sounds like this is what you created), you need to **Tenants -> Your Tenant ** and then select the OAuth tab and choose the Client Credentials populate lambda.

Client Credentials JWT Populate lambda documentation

JWT Populate lambda documentation

@sandesh Great, glad you figured it out!

@mark-robustelli we are on the old 1.6. I cannot add the tenant back since this is a production server and a second tenant breaks our application authentication service. Upgrading right now is not an option and we are working on trying to migrate to hosted cloud services as our upgrade path.

@ronn316 Awesome glad to see you got it working. I'm sure there is a way to use a dns name, but like I mentioned before, someone with a little more docker experience would have to help us out here. Thanks for working this through and sharing with the community.

Hey folks,

Coming from the future. I just decided to change my docker-compose.yml to use network_mode: host therefore my former comment is no longer valid. Please look at my monorepo on how I am utilizing Terraform, Docker, mailcatcher as my local SMTP, NestJS, and NextJS.

I also wrote a couple of README.mds here and there for future references.

Feel free to give it a star on GitHub and or better yet use it.

@egli said in Upgrading from 1.46.0 to 1.47.1 CSRF token issue with IdP:

Similar issue and was able to resolve it by following changes mentioned here:
https://fusionauth.io/docs/release-notes/#version-1-47-0 slice master

Can you explain in more detail?

@sandiprghane based on that info, I think the above method will work for you and as I mentioned, maybe check out custom scopes for third party applications if you have a license that supports it.

Well, since we're talking about behavior based on a fix that isn't written yet, things are a bit theoretical. 🙂

Here's one approach we'd consider. An expired key pair cannot be used to sign a JWT, so we would either have to generate a new key pair ahead of the expiration, or start failing login operations. The former is a better user experience, so a user will either have to regenerate the key, or we would do it based upon a configured policy.

Also, wanted to be clear that we are aware of this limitation, which is why we set the default expiration period to 10 years (so we have a bit of time to solve this in the best way possible).

Hope this helps. Let me know if you don't have the information you need.

As of q4 2021, FusionAuth officially supports Kubernetes.

You can read the docs here: https://fusionauth.io/docs/v1/tech/installation-guide/kubernetes/

@dan 160ms

Another option that works as of today is to set up a tenant to tenant connector.

Add a connector to the new tenant. Point it at the /api/login endpoint of the old tenant, including an API key as a header.

Change your app to send everyone to a new application in the new tenant.

When the user logs in to the new application, if it is the first time they've been seen, the old tenant data, including password, will be queried. The password hash will be transparently migrated to the new tenant.

This slow migration takes time, but is another option.