Topics created by ashok

@ashok

I think that your initial assessments are correct. You should be able to create an application, and that would generate a unique client secret.

The API below would be where I would start.
https://fusionauth.io/docs/v1/tech/apis/applications/#create-an-application

If you have a few more questions related to the specific technical challenges you see from this approach, we could consider them here as well 🙂

Thanks,
Josh

Well, I'd just call the 'create registration' API from the server three times after a user had successfully registered on your custom page: https://fusionauth.io/docs/v1/tech/apis/registrations#create-a-user-registration-for-an-existing-user

Does that make sense, or do I misunderstand your question?

Great. It's typically used for CSRF protection, but can be used for other purposes. Here's a pretty good article covering this.

I totally forgot to add the register the user manually to the FusionAuth application. It is working now, thank you!

@ashok glad you solved the problem!

The only problem is that I don't seem to be able to pass all the tokens and then "map" it out in the backend.

I'm not sure what you mean here. Are you not seeing all the tokens in the lambda? Or are you not able to put them all in the custom claim?

Also, I think I already know the answer to this and this may sound dumb, but how can you have multiple tokens? A user with multiple providers? If so, how are they consolidated and combined?

A token is tied to a registration/application, so someone could login with google to one FusionAuth application and with facebook to another. Unless I'm missing something, I don't believe they are combined.

Lastly, it would have been nice if user.registrations had a providers field.

We welcome your feature requests 🙂 . Please file a github issue: https://github.com/fusionauth/fusionauth-issues/issues

Thanks for the reply @dan.
We ended up storing sub ID on our side. We thought that might gives us more flexibility down the road (not sure about this but if it doesn't work then we'll have an extra column in the db; a small price to pay IMHO).

"Where to map the ID?" was a bit headache for us as we didn't want to miss it or make an extra call by polling ourselves. Since we are using .NET Core, we ended up hooking into OnUserInformationReceived event, one of many from OpenIdConnectEvents. Hopefully, I'm not doing something really stupid.