FusionAuth provides a feature called Identity Provider (IdP) Linking Strategies that allows you to link social login accounts to existing FusionAuth accounts. This feature is available since version 1.28.0.

There are several strategies you can use to link accounts:

1. Link On Email: This strategy will create a new user if they don’t exist. However, if the user has an email address at their social provider which differs from the email address that was used to sign up for your application and which you imported to FusionAuth, then two accounts will be created.

2. Link On Username: Similar to the Link On Email strategy, this will also create a new user if they don’t exist. But it has a greater risk of account takeover and should be used with caution. In most cases, you would never want to enable more than one identity provider to link by username because there could be a username collision.

3. Pending: This strategy will prompt the end user to sign into FusionAuth after they sign into the social provider, authoritatively linking the two accounts.

To implement this, you'd have to get the user to login via their social account and get their unique user Id. Then you'd take that user Id and create a link using the APIs. After the link is created, the next time the user went to login, they could use either their old email/password credentials or the linked social login.

Here's more information about IdP Linking Strategies.

Sources:

• FusionAuth 1.28 Announcement
• FusionAuth Community Forum
• FusionAuth Documentation

@justin-calareso to test this screen, you can always select preview on your theme to see if it would work if needed.

Then select the "Confirmation required" screen. Notice how I put "Alex did this" on this confirmation.

One of the easiest ways to try this out is to use Passwordless login. As you can see in the Theme I have the confirmation page example set which I added <h1>Confirmation page example</h1>

Now when I log in to the application I am presented with the option for "Login with magic link"

This will email me a link which I can open in a new private window (or different browser not already logged into the application).

Once I open this in the new window you will see that the confirmation required has my H1 tag showing "Confirmation page example".

I hope this helps.

This might be useful for visitors in the future: https://fusionauth.io/docs/extend/examples/device-limiting

Hiya @kasir-barati ,

You can certainly use just a subset of known invite codes. In that case, no need to store the codes on the user.

Instead, add an array of codes in the self-service registration lambda and have a step check to see that the user provided code value matches one of the known values in the array.

This isn't out of the box, but is relatively easy to implement.

• After each user is added successfully, create a list of codes in their user.data.inviteCodes field (which can be an array). It's a good idea to have the codes be alphanumeric because FusionAuth's elastic search indexing handles those types of values best. Let's call this user the inviter user. Make sure each code is unique across all users.
• When a user tries to register with a code, let's call that user the invitee user.
• Build a page in your application to display the list of user.data.inviteCodes to prospective inviters.
• Create a custom registration form and have one of the fields be an invite code, to be provided by the invitee user (because they got it from the inviter user).
  • You could prepopulate this via a link by customizing the theme and having javascript pull the value from a query parameter and put it into the form.
• Create a self-service registration validation lambda.
• In that lambda, search for the code.
• If it is not found, add an error. This error will prevent the user from registering.
• If it is found, take the following steps:
  • Allow the registration to succeed.
  • Add a webhook to listen for the create user event, which reads the invitation code.
  • From the webhook, update the inviter user to remove the used code from the user.data.inviteCodes, which means that code can't be used by future invitees.
  • That same webhook can update the invitee's user.data.inviteCodes field so that they can now become inviters (or maybe that happens later, depending on business logic).

If invitees use the same code within time period the elasticsearch index is updated (usually 1 second), there may be a race condition that would allow two invitees to register with the same code.

If absolute isolation in the invite code processing is important, use Lambda HTTP connect in the self-service registration validation lambda to check if a code is valid, and have that read from an RDBMS.

In this case, you'll need to provide the code and the inviter email address in the form so the lambda can provide it to the API. These fields can both be hidden.

You can also consider adding an expiry timestamp to the user.data.inviteCodes if that functionality is needed.

Here's an example of the user.data.inviteCodes value:

"inviteCodes" : [
 { 
   "invcode": "abc123",
   "exp":  1712679467
 },
 {
   "invcode": "234jklasdf",
   "exp":  183678467
 }
]

And here's an example of a queryString that will pull the user with the abc123 invite code, or return zero records if that is not found.

data.inviteCodes.invcode:abc123

Read more about elasticsearch arrays.

I have an application that I want to invite users to and want users to be able to invite users to. I do not want to allow users to register for this application without being invited.

I've seen: https://fusionauth.io/community/forum/topic/935/how-to-implement-user-invitation but was wondering what the current best practice is.

@ronn316 Hey - the easiest way to prevent indexing on any pages you don't want indexed is to add a meta tag to the templates. Something that looks like this -> <meta name="robots" content="noindex">

Cheers,
Tony

@jacob-0 Sorry to hear you are having issues. Thank you for the detailed post explaining it. Unfortunately, random unavailability can be very difficult to troubleshoot.

Based on your explanation, it seems as though the instance is available from outside the GKE cluster. Could this be an issue with one of the pods going down and being restarted and the internal networking not recognizing the change? I don't quite see how it would still work from the outside, but is there any evidence of pods restarting around the down time?

@yuriy-barvenko Performance tweaking can be tricky. It really depends on what your goals are. If you create indexes to improve searching things, it could slow other things down like the login. It may also depend on which database you are using. What DB are you using? What is the purpose of the information you are trying to get? Does it have to be real time? Are there alternatives like data dumps that you could use? Also, you say "the response times are significantly higher than expected." What is this based on? How many users and roles do you have in the system and what is the expected response time? What is the requirement for response time vs what is expected?

@bill-yudichak Can you please get us a little more detail. A screenshot may help. I do not see a "Go Back" link when I enable multi-factor for my app. Also, what is the accountTwoFactorIndex template you are referring to?