Let's discuss federation. In general, this is where there's a trust relationship between two or more identity stores, and where a user can sign into one system based on the promises of another system.
What is CIAM federation?
In CIAM, federation is a situation where the user signs up in your system, but you never see the credentials. Instead, the credentials are controlled by a third party like Google, GitHub or an OIDC provider, which provide you a promise that the authentication event happened.
With customer identity, this is typically done with one of two options:
social providers such as Facebook, Apple, or Google. The protocol is defined by these large providers of consumer identity. They also vary based on locality (Xing for Germany, WeChat for China) and user type (GitHub for developers, LinkedIn for business folk). This is appropriate for B2C scenarios where your users are individuals. Apple and Google are also common choices for mobile login.
business managed providers such as Google workspace, Okta, or Azure AD. These are typically using the SAML or OIDC protocols, and there tend to be many of these. This is appropriate for B2B or B2B2E scenarios where your users are employees of businesses.
In either of these cases, the user is usually created at the first authentication event. That is, the user visits your application, chooses to authenticate with one of these remote user data stores, then an account is created in your system. You can then use this account in your application. Future authentication events may update this account (if profile data is returned), but won't provision new accounts.
This leads to one of the subtle complexities of federation, account linking. Let's look at a common consumer application scenario where an application (cool app XYZ) has multiple different social sign-on methods.
Account linking
Dan goes to cool app XYZ initially. He signs up using Google.
Then he forgets about it. Three months later, after an interesting email from marketing, Dan returns. He doesn't remember what he signed up with, so he signs up with Facebook.
Then he forgets about it. Six months later, Dan returns because he now needs cool app XYZ. He again doesn't remember what account he signed up with, so he signs up with Apple.
Does Dan have three different accounts? Or one? Or some other number?
Ideally for the business, Dan would have one single account, with three different links to Google, Facebook and Apple. Linking users across different systems on authentication lets the application have a truer view of the end user. After all, there is only one Dan, so why would there be three different accounts? Account proliferation should be avoided if possible.
Linking has issues, however, because it depends on matching user data across remote data stores. You have some options, none of which are perfect.
you can ask the user to link other accounts in your application. So Dan could, after logging in with one social provider, choose to connect other social providers to his account in cool app XYZ. This is a pain and there's not a lot of value to the end user.
you can build automated account merging based on attributes of the user. This is useful if you have real world information such as an insurance policy number or government identifier. The risk of a mistake, which is account takeover, means that this is a hard problem to solve if you lack that.
customer service reps can merge accounts based on their judgement. This is highly manual and only worthwhile for very high-value accounts.
you could look for a common identifier across the remote data stores. A common choice is email address but that is by no means guaranteed to be shared between all these providers. You can also use phone number, which is more accurate but not guaranteed to be available.
One way to help minimize multiple account creation is to remind the user which social provider they used last time they logged in on a particular device. In a multi-device world that doesn't solve the problem all the time, but may help certain applications. For instance, some applications are more likely to be accessed in a browser, while others are more likely to be accessed via a mobile device. For these, a reminder ("you logged in with Google last time") may circumvent account proliferation.
Finally, linking is not typically a problem for business provider federation. In that case, there's not multiple remote data stores.
Benefits and tradeoffs
There are definitely benefits to federation:
the user has one less account to keep track of
there is lower friction in the sign-up process
complexities in account recovery, preventing enumeration, account validation, and profile updates all are delegated to the remote identity store. Whee!
in the business scenario, you have centralized access control; once a user is not in the source directory, access to all other systems is revoked
Of course, there are tradeoffs.
with social providers, you may not get as much data as you want. You may still have to ask for additional data to provide your services, such as birth date or payment data. So you still have an on-site registration flow.
profile changes may not be propagated
with social providers, if user loses their account access, they can't get into your system. Good luck getting Google or other big providers to care.
in the same vein, your app also needs to be approved/blessed by provider and access can be revoked.
Additional concerns
Beyond linking there are some other complexities around CIAM federation. These include:
considering the overall threat model if you allow users to set up their own identity providers and log into an application, which is common functionality for B2B scenarios. If I set up a remote identity provider and create an account for dan@example.com, will that lead to account takeover of any other dan@example.com accounts?
thinking about what additional validation, if any, is needed for a federated account. Above, I mentioned collecting additional profile information, but you may also want to allow or require additional factors (MFA) for the account in your application. What about verifying ownership of email?
In general federation should be used to decrease the friction of sign-ups for consumer applications or to offer needed control to business applications.
Dan