Why Account Linking Should Be Pivotal In Your CIAM SSO Integration

Reading Time: 11 minutes

Leveraging SSO (a.k.a. Single Sign On) as part of a CIAM integration provides significant benefits when it comes to building your SaaS solution. From user convenience, rich user profiling, and attack protection provided by the Social authentication mechanisms, to the business benefits that (Enterprise) Federation provides in B2B scenarios, SSO gives your customers the sort of seamless experience I’ve talked about previously in videos such as Be More Social With Your CIAM Integration, Vibe Coding Authentication via Authorization Code Flow, and of course my article:

In each of those previous publications, I’ve touched on the topic of Account Linking — arguably, one of the most transformative yet underappreciated capabilities in a customer identity context, particularly when it comes to SSO. My name’s Peter Fernandez, and in this article, I’m going to show you why and how Account Linking plays a pivotal role and why you need to leverage it as part of your CIAM integration.

What is Account Linking?

In a nutshell, account linking refers to the process of connecting multiple identities belonging to the same person across various systems, platforms, and identity providers (IdPs), mitigating identity fragmentation. What do I mean by multiple identities and identity fragmentation? Well, consider, for example, how a user may have implicitly signed up using their Google account, say, and then later they log in using their LinkedIn, GitHub or even Facebook account; without account linking, each of those would typically present as an individual, unique and distinct user to a SaaS solution, leading to confusion and disconnection from a user perspective:

• Inconsistent and de-personalised experiences
• Fragmented view of a customer
• Duplication of user records
• Weakening of security controls

Common Use Cases

Implementing account linking thoughtfully — balancing user control, privacy, and business value — will invariably unlock richer insights and stronger relationships with customers, seeing and serving the customer as a whole, no matter how they choose to connect:

• Multiple Identity Providers. Many CIAM integrations support Social login (e.g., Google, Facebook) in addition to (Enterprise) Federation and the more traditional UserID/Password credentials. A user might first log in via Facebook and later via their Microsoft or Google account, say; without account linking, a SaaS solution will see two users, but with linking, it sees the same person.
• Mergers and Acquisitions. When companies merge, they may need to unify user bases from different identity systems. Account linking can reconcile duplicate accounts and maintain continuity for users.
• Multiple Brands or Products. Companies with multiple brands (e.g., automotive, travel, or media conglomerates, say), may have users who create accounts on different brand platforms, but SSO combined with account linking ensures a unified brand experience.

Why is Account Linking Important?

If you only ever use one login method as part of SSO — i.e. UserID and Password, say —then on the face of it, you don’t need to link accounts, right? Well, that is true to an extent, but not in all use cases. Besides, if you’re only leveraging UserID and Password, you’re missing out on the opportunities provided by the likes of Social, passwordless or password-free workflows, and for B2B SaaS solutions, you will lack the competitive value provided by Federation.

As a rule, there is typically a 1:1 correlation between a user identity and their account; by default, most identity provision works on the basis that every user has exactly one account. And an account/user is typically created either explicitly — i.e. via signup or via some management dashboard/API process — or implicitly when login occurs via some upstream IdP (such as a Social or Federation connection).

By linking accounts, a 1-to-many relationship is created between a user identity and their related accounts. Users don’t have to remember which login methods they used, as account linking ensures that all accounts related to the user are seamlessly connected — and by implication, a SaaS solution automatically recognises any related login as belonging to the same person. The SaaS solution can then utilise the unified user account and offer consistent experiences no matter what mechanism a customer uses to validate their credentials:

• Consistent Personalisation: When customer data is unified, tailored content, recommendations, and services can be offered regardless of how or where a user logs in.
• Elimination of Duplicate Accounts: Without account linking, multiple accounts are unknowingly created, leading to confusion and loss of saved preferences or history.
• Smooth Onboarding and Cross-App Transitions: In SaaS solutions leveraging multiple services, a linked account allows users to move between these seamlessly without disruption.

Account linking also ensures that customer data is not siloed across services, enabling deeper insights and more effective decision-making: if a user is recognised consistently, no matter how they log in — or to which ever application/service that is part of a SaaS solution — then fragmentation of the metrics obtained about a customer is mitigated, making it easier to track and measure behaviour.

• 360-Degree Customer View: A holistic understanding of customer behaviour can be obtained across different touchpoints, devices, and login methods.
• Improved Analytics and Reporting: Unified data supports better segmentation, campaign effectiveness tracking, and journey analysis.
• Data-Driven Personalisation: Personalised marketing and product recommendations rely on comprehensive user profiles, which are made possible through account linking.

From a security perspective, account linking helps to enforce consistent authentication and authorization rules across a SaaS solution, improving the overall security posture. Fewer accounts mean fewer opportunities for attackers to exploit credential weaknesses to gain unauthorised access, and with linked accounts, unusual behaviour — e.g., a sudden change in login method or location — can be flagged more accurately. Secure account linking will also typically involve some form of identity verification, which reduces the risk of impersonation or account takeover, and I’ll be discussing this more in the section below.

Consistent Customer Identification

Let me elaborate. In a CIAM-integrated SaaS solution, a customer account is usually referenced by some unique identifier; how that identifier is generated and what it might look like, I’ll talk more about later. For now, it’s enough to know that whilst such an identifier is not necessarily designed to replace any account identifier(s) already in use by any specific aspect of the solution (i.e. any particular application or service), it is certainly meant to augment them. It essentially provides an overarchingly consistent identification of a user account — and by implication, a user — across all applications in a SaaS solution. Importantly, it is also designed to be opaque: as a best practice, such an identifier should never expose user PII in any form.

By way of example, the first screenshot above shows the user record generated by the Keycloak IdP, for me, as a customer of the B2B SaaS solution I’m building — a Production Management solution for theatrical stage shows, cooked by WOK (WordPress, OpenFGA and Keycloak) — and I’ve highlighted the user identifier assigned by Keycloak. The second screenshot, below, shows the account record generated for me, as a user, in WordPress (with its own WordPress user_id account identifier) and where data from the IdP (Keycloak) has been attached as WordPress metadata; again, I’ve highlighted the sub claim from the id_token as the identifier from above, and I’ve also shown the data record as it appears in the database so that you can see the specific details.

In contrast, this next screenshot (below) shows an example relationship created in OpenFGA — i.e. a ReBAC modelled definition — for me as a participant in a fictitious stage production; again highlighting the identifier for me as a user. Note how 9e287646-7e43-45e6-ad82-cc138e1deaae is common across all three definitions as the unique identifier tying together all the records associated with me (as a user), irrespective of any additional application-specific account ID(s) — e.g. the user_id identifier that, in this case, WordPress also employs.

The problem arises when the same user chooses to use a different login method, either intentionally or accidentally. They will, by default, essentially appear to the IdP (Keycloak) as a completely separate user; in a default 1:1 correlation, a new login via a new Social or Federation account, say, automatically creates a new user and, by implication, a new account. If we were to now revisit the scenario above, and where I were to choose a different login method, without the ability to account link, things change significantly:

• Keycloak generates a new user/account, so the associated identifier is different; I’m essentially a different user
• WordPress generates an error because, typically, an attempt will be made to create a new user with an email address that already exists in its system. As described below, account linking will often use email as a recognised mechanism for identity resolution, and as per the official WordPress documentation, “…Each WordPress.com account must have a unique email address, and email addresses cannot be shared among accounts. That is, one email address cannot be registered with multiple accounts…”
  • A mandatory requirement fo unique email addresses is not uncommon, and when using third-party (open-source) applications/systems as part of your SaaS solution, means you have little choice to do anything other than comply with the way it works.
• OpenFGA definitions no longer apply, because they’re effectively associated with a completely different user. This means that any access privileges provided will no longer apply, as essentially, the relationships defined will also not apply.  

Omnichannel Experience

Account linking ensures that omnichannel strategies can be effectively executed, regardless of how the user logs in. Customers will, more often than not, interact with a SaaS solution via web, mobile, kiosk, smart TVs, and even voice assistant apps. Each of these will typically leverage native account identifiers, and so account linking allows for a continuous identity across these channels:

• Cross-Device Continuity: A user who adds items to their cart on the mobile app can easily complete checkout from a desktop.
• Unified Preferences and Settings: Notification settings, accessibility preferences, and saved items persist across platforms.
• Consistent Branding and Interaction: Linked accounts allow for coordinated, personalised touchpoints throughout the customer journey.

Compliance with Privacy and Data Regulations

Data privacy regulations such as GDPR, CCPA, and others require organisations to (a) know what data they hold about individuals and (b) allow individuals to access, correct, or delete that data. By mitigating fragmentation, account linking enables organisations to comply with these mandates more easily:

• Avoiding Data Duplication: Redundant data from multiple unlinked accounts increases complexity and compliance risk.
• Simplifying Data Subject Requests: Linked accounts ensure that when a user requests data deletion or export, all related records are handled appropriately.
• Consistent Consent Management: If a user withdraws consent on one channel, account linking ensures this applies across the entire identity ecosystem.

How is Account Linking Achieved?

As illustrated in the section above, 9e287646-7e43-45e6-ad82-cc138e1deaae represents the identifier uniquely created for me as a user, and in my case, this identifier was created by the Keycloak IdP when my user was created — again, in my case, by implicit signup as part of my first login via a Social provider. In a CIAM context, it’s almost invariably the role of the IdP to create the user record and subsequently to generate the unique account identifier associated with it, whether implicitly or explicitly (i.e. via explicit signup or account creation via some explicit management API call).

Ergo, it makes sense for the IdP to be responsible for the account linking process too, and in a CIAM integration, this is exactly the case. The (multiple) applications in a SaaS solution will leverage the centralised identity infrastructure provided by an IdP, so centralised account linking performed by the IdP ensures that all related accounts are consistently recognised as the same user. The actual mechanics of account linking become the responsibility of the IdP, typically resulting in the 1-to-many relationship being maintained and managed within the context of the IdP, and each application can go about its business without concern for user duplication.

However, not all CIAM solutions make Account Linking easy to achieve; arguably, a key factor for why many developers don’t consider adopting SSO multi-strategy authentication (e.g. adding Social) as part of their CIAM integration. Previously, I came across the following post on LinkedIn, and whilst Frontegg is known for this kind of marketing approach, as a veteran of Okta/Auth0 it did make me smile 😊 During my time working with the Auth0 platform from Okta, I came to know that much of its power comes from the toolkit-like nature that allows for integration in some complex scenarios; I often analogised Auth0 to being like a CIAM toolbox full of CIAM tools.

I’m not suggesting Frontegg is any better in the way it provides CIAM workflow solutions, but it’s certainly true to say that the toolbox approach is not everyone’s cup of tea. If you’re going to pay a not insignificant sum for a subscription to some 3rd-party CIAM vendor-hosted SaaS solution, you don’t necessarily want to hear “…yes, you can do that, but you’ll have to build that capability yourself using the tools we provide…” It’s like buying a Range Rover and then being asked to DIY the assembly! And it’s particularly true with account linking if you’re left to deal with the specific security challenges (see below for more details) that can lead to account vulnerability!

Whilst the ready-made out of box Keycloak solution for account linking isn’t perfect, as a toolkit-oriented CIAM option for a DIY based approach (read more in my article Build, Buy or DIY your CIAM Solution), it typically comes at no cost and, as an open-source solution, means you can also augment the default behaviour to provide a more secure experience. Something I will be discussing in a future article 😎

Alternative Approach

One alternative to account linking is for each application to detect a duplicate account, and then make multiple associations at the application level — e.g. reflect the 1-to-many relationship within the context of the application. Something I’ve seen happen, especially where SaaS developers end up struggling with the account linking intricacies posed by their IdP of choice.

However, this is not a recommended course of action: not only is it a costly endeavour, both in terms of development effort and maintenance, but it will almost certainly lead to inconsistency. And invariably, there will be duplication of data. Further, if some leveraged third-party application or service has particular restrictions (such as with my WordPress scenario illustrated above), a development team will need to be aware of them and take this into consideration as part of their implementation design.

Challenges

Despite its benefits, account linking poses a number of challenges. A poorly implemented account linking strategy can introduce vulnerabilities — for example, if a malicious actor can trick the system into linking their account to a potential victim’s, they can gain unauthorised access. So, careful considerations, including strong verification processes and continuous monitoring, are essential to mitigating such risks:

• Identity Resolution. Determining that two accounts belong to the same user is non-trivial. The linking of accounts must balance accuracy with user convenience, typically using the likes of email address matching, coupled with out-of-band verification and optional MFA, to ensure that account linking is safe and secure. coupled with MFA and out-of-band verification.
• User Consent and Control. Users should be aware when accounts are being linked and must explicitly consent to it. To meet with regulatory compliance, amongst other things, the account linking process should:
  • Provide transparent messaging
  • Allow users to manage linked accounts
  • Support unlinking if needed/required.
• Data Reconciliation. When linking accounts, any conflict in user data (e.g., different profile pictures or contact info) must be handled, with strategies in place to help maintain a single source of truth.:
  • Prioritise based on trust
  • Ask users to confirm as part of the linking process
  • Merge data safely, allowing users to control their linked accounts and understand what data is shared.