Distributed Identity
In this problem domain, any given user can be represented across disparate systems, each with its own different user identifiers in use. For example, a ticketing system usually has its own representation of the user, as does a retail provider, and so on.
We think of this as the user's distributed identity.
In a platform that aims to create a unified D2C experience across disparate systems, such as OneBasket, this fragmentation of identity is problematic, as we need a way to identity a single person in multiple systems so that we can connect their data to their transactional activities.
Often, one of these systems at some point in the past was selected to be the "source of truth" for sign in in the organisation's ecosystem. This creates further problems to solve, as the concept of the "identity provider" has been tied in with one of the product provider systems. This is where an SSO system comes in.
Unifying identity with SSO
The seemingly obvious solution to this problem is the implementation of a Single Sign On (SSO) solution.
An SSO system's sole purpose is to manage the identity and authentication of a given person, becoming the source of truth for that user across all systems.
Third party provider systems with their own concept of a user then, in theory, link their user IDs to the SSO's systems "soure of truth" identity, and that user can then be represented across all systems with the identity of the user in the SSO system.
SSO systems can of course do much more than this, and we'll talk about some of these things later on in this section.
The main idea is that a given user signs in once with the SSO system, and then that login credentials is then valid across all other disparate systems that integrate with SSO. The user can then navigate across each service's web site without having to log in again.
OneBasket comes out of the box with the ability to integrate with SSO systems, including an OIDC compliant authentication mechanism. See the section on Authorisation for more information about this.
Unfortunately, provider systems often lack the technical ability to complete a full integration with the SSO system. This creates a halfway state, where the user has a source of truth identity in more than one system.
Identifying users through API endpoints
So far we have only talked about an SSO solution allowing a user to sign in and navigate across different web sites, however when it comes to OneBasket, we're typically ontly talking about machine to machine integrations through APIs.
In a perfect world, once a full SSO integration has been complete across all systems, OneBasket's servers could communicate with all third party APIs by simply using the user's SSO Id. The external system would then handle the mapping between the SSO Id and its own internal user ID on its side.
Unfortunately, this isn't the normal case. Whilst services sometimes provide OneBasket with a way for to manually map between the SSO Id and the user id in the external system, usually the API endpoints typically require the usage of the provider's own ID. This makes sense of course — provider systems exist independently of any SSO system in use.
All this is to say that an SSO integration only takes us part the way there to creating a seamless experience for users, who ideally, shouldn't have any idea that they are dealing with multiple systems. Our aim is for our customer's customers to percieve products and services coming from their own ecosystem, not from the providers themselves.
The solution here is for OneBasket to keep a reference internally of all the links between a contact across different systems. This involves a number of different edge cases that must be solved for, which we'll go through next.