Account Linking

Heya,

I thought this article by Peter Fernandez was a good look at account linking and discusses the issues with it.

The article argues that account linking is essential in customer identity and access management (CIAM) federated integrations. It unifies customer identities across multiple login methods (like Google, LinkedIn, or Facebook). Without account linking, users who log in via different identity providers appear as separate users to a SaaS solution, creating fragmented experiences, duplicate records, and weakened security.

Peter emphasizes that linking accounts provides consistent customer identification across all applications, enables a 360-degree customer view, and improves compliance with privacy regulations like GDPR by simplifying data management. The article also discusses implementation challenges around identity resolution, user consent, and security verification to prevent account takeover attacks.

Peter’s article got me thinking about the deeper technical challenges that make account linking so tricky. In my experience, account linking is similar to the issue with tenant discovery--you don’t have a full picture of the user but are trying to make security and identity related decisions anyway.

The Core Problem

After a successful federated login, most identity providers give you back a unique id for the user in their system (the ‘sub’ claim) as well as other data related to the person, such as email address or given name.

The unique id usually does not change over time, but that is not guaranteed. This id isn’t helpful for linking accounts, since it is not the same across systems.

The other returned data such as email address can be used to link accounts, but will change over time. So you can use it to connect across accounts at the moment, but not over time.

If you are lucky, you might get more permanent identifiers like government id, but that really depends on the remote identity provider. If you are in a consumer context, this is unlikely.

So connecting accounts across systems is a real challenge.

Possible Solutions

In its most straightforward implementation, matching email addresses between different identity providers to link accounts works. This also works with other cross-system identifiers such as phone numbers or usernames, but email address is the most common.

If someone logs in with with Google and has an account dan@example.com, then later logs in with Facebook, where they have the same email address, you can match those accounts. Make sure to store the unique ids from Google and Facebook. If later they change their email address in Facebook to daniel@example.com, Facebook should still send the same unique id and you won’t create a separate account.

The issue with this approach, of course, is what happens if they log in a third time using LinkedIn, but have an email address of danmoore@example.com with that provider? There’s no way you can automatically match dan@example.com and danmoore@example.com.

You can work around this by requiring email verification to prove remote account ownership, surfacing this complexity to the end user, and allowing the user to manage and join accounts. Of course, the user needs to be relatively savvy to do such joining. And they need to have incentive to do so.

Account linking is most useful when the users are consumers or small business employees. When your users belong to larger businesses, they are likely to have a single source of user identity, not multiple options.

When You Don’t Want To Link

There are times when you might not want to link users across different accounts.

One scenario where this might happen is if a user is using a remote federation source to give access to that source’s data (Google drive data, LinkedIn contacts) and would be surprised if this data was mingled. If users want to choose different federation providers intentionally to fragment their identity in your application, you should let them.

Avoid account link when the fragmentation benefit outweighs the system benefits of a single user identity.

Preferred Accounts

Another feature which complements account linking is highlighting the user’s preferred account.

If they’ve logged in with Google before on that device, when they return to the login page, tell them that!

Sessionize does a good job of this, where they tell you which method you used to log in last time on this device. Below is a screenshot of their login screen, with a list of federated identity providers, highlighting the Google option.

Account linking isn’t simple, but implementing it avoids fragmented user data, one of the main goals of using an CIAM system in the first place. If you are offering federation to consumers and small business employees, it’s unavoidable.

Cheers,

Dan