Posts made by pavol

@dan Sorry I think I lost the notification about your reply somewhere.

Basically, it seems like the issue is there is data you send during the login which you want stored in user.data. You can do this with the user create API but not with the idp login API call.

Almost, it's not during login but during registration, just with idp it's a login call that can result in registration.

I think being able to solve this would solve the issue.

The suggestions you gave are not very atomic. We have many users with spotty network connections, so we're trying to stick here with 1 API call for registrations.

Hi!
We're currently migrating our auth system into FA. During 3rd party login migration, we found out that our login and sign-up scenarios are not completely covered by FA OR I am missing on how to complete some steps here.

We have 3 scenarios when users are coming into our app through 3rd party login (google, apple...).

1. The user already has an account, calling the identity provider login API will result in them getting into the app.
2. The user has an account but is using a new identity provider to log in. Using automatic linking, calling identity provider login will have the same result as scenario #1.
3. The user has no account, calling identity provider login will create a new account for them and have the same result as scenario #1.

Now scenario #3 is where we have some problems. If we are creating accounts using the create user API call, we can supply extra metadata about the user in the data property. Then we can pick them up using the user.create webhook.
This option is simply not there for identity provider login. Anything provided in the data prop will be stripped and not visible in the webhook event.

This made me look into the option of Link On Email. Do not create the user if they do not exist. This would work if we also got more info from the failed identity provider login (such as email and 3rd party token). Then we could attach it to the create user request body and have more control over what we're putting into the data there.

So this made me look into the Create a Pending Link option. This however breaks scenario #2 AND the pending link doesn't return with email/username information so we don't know what to put into the create user request body.

This makes me believe that fusionauth could benefit from 2 things:

1. Add option Link Existing User and Create pending link for new user in identity provider settings
2. Return the email/username with the pending link so we can create users more easily.

I also noticed that there's eventInfo in the request body of the identity provider login call and that one will show in the user.create event, but I can't find docs about this, so I am not sure if this is what it's meant for.