Abusing federation and account linking
Trusting the wrong sign-in
The photo application lets customers create an account with an email address and a passkey. It also lets them sign in with accounts they already have elsewhere: a large consumer identity provider at id.example.test, a smaller social site at social.example.test, and, for business customers, their company's own identity provider. Each provider the application accepts is a door into it. Whatever a trusted provider asserts about who signed in, the application believes, as Trust across systems explains. The application can check that a message is genuine and meant for it. It cannot check whether the provider told the truth.
That makes the application only as strict as the least careful provider it trusts. Some providers let anyone create an account and type any name or email address into their profile. Some host sign-in for many organizations, so anyone can create a new organization there and become its administrator. A business partner's identity provider may be run with less care than the application's own sign-in. An attacker who controls a trusted provider, by running one, creating a tenant at one, or taking one over, can make it assert whatever they like about who signed in. At a provider that hosts many organizations, only the issuer shows which tenant is speaking, which is why Forged tokens and stolen signing keys treats accepting another tenant's issuer as a validation flaw.
A provider speaks with authority about its own users: the accounts it created and the subject identifiers it assigned. Trouble starts when an application lets a provider's statement decide which of the application's own accounts someone may enter.
Matching on the wrong attribute
The simplest form of that mistake is linking on email. A sign-in arrives from a provider with the email address of an existing photo account, and the application treats the person as that account's owner. Now look at it from the attacker's side. They sign up at a provider the application trusts, set their profile email to the victim's address, and sign in to the photo application through that provider. The provider asserts the address because the attacker typed it. The application finds an existing account with the same address, links the new sign-in to it, and opens the victim's albums.
Email fails as a key in several ways. Some providers never verify the addresses people enter. Some verify an address once and then let the person change it without checking again. Addresses are reassigned when someone leaves a company or abandons a mailbox, and a lapsed domain can be registered by someone new, along with every address under it. Usernames, phone numbers, and display names share the weakness: they describe an account at a moment in time, and they can change hands.
The stable key is the pair of issuer and subject: the provider's identifier, and the identifier it assigned to this person and never reassigns. Trust across systems explained why both are needed. The application stores that pair on the account when a link is created and, on later sign-ins, looks the pair up and ignores the email. Creating a new link to an existing account requires the person to prove control of that account first, by signing in with its own methods, as the same lesson's section on linking accounts safely describes. Linking accounts covers the cases where even a verified email claim is not enough, and walks through a safe linking flow step by step.
The attack also leaves evidence. The victim's account gains a linked identity from an issuer it never used before, followed by sign-ins through that issuer from an unfamiliar network. A notice to the owner's existing verified address whenever a new way to sign in is linked gives them a chance to react, and the link itself belongs in the account's history.
Each sign-in below arrives at the photo application. Decide what it should do.
Link or refuse?
Simulation. These sign-ins are made up, and answering sends nothing. Each one arrives at the photo application; decide what it should do.
Adding a door of your own
An attacker with administrative access to an organization's identity configuration does not need to trick a provider. They can add one. Workforce identity systems let administrators trust another identity provider, accept sign-ins for a domain from an outside source, or add a signing certificate to an existing federation trust. Each is a legitimate feature for mergers, partners, and migrations. In the wrong hands, each creates a door that signs in as any user the attacker chooses, with no password or second factor from the real person.
Claim mappings offer a quieter route. A mapping decides which attribute from a provider identifies the account, or which group grants which role. Changing it so that a value the attacker controls decides who signs in, or so that a group they belong to maps to an administrator role, turns an ordinary sign-in into a privileged one without adding anything to the list of providers.
These doors survive the usual clean-up. Resetting passwords, revoking sessions, and removing an attacker's authenticator do nothing to a trusted provider the attacker runs, which is why it is a favored way to keep access, as How attackers stay in describes. In the Cedar Inc. incident, the attacker's call to the help desk for an administrator's MFA reset was refused, but had it succeeded, they would have held exactly the access that changes like these require.
Watching trust configuration
Trust configuration decides who can sign in as whom, so changing it needs the protection given to the most privileged roles. Only a few administrators should be able to add a provider, a signing certificate, or a claim mapping. Each change should require a fresh, phishing-resistant sign-in, and adding a provider can reasonably need a second administrator's approval. Protecting privileged access describes these controls.
Every change should be recorded with who made it, from where, and the values before and after. A new provider can sign in as any user it is mapped to, and it keeps working after every password in the organization has been reset, so a security team wants to hear about one within minutes, not at the next quarterly review. Because these changes are rare, an alert on each new provider, domain, certificate, or mapping change is seldom noise.
Regular review closes the loop. Compare the trusted providers and certificates with the partnerships the organization actually has, confirm that each certificate matches what the partner publishes, and look closely at sign-ins through rarely used providers, especially into administrator accounts. Recording identity activity and Reviewing identity security posture cover how to keep those records and make the checks routine.