Identity Sources and Data

Where consumer identities come from and where they live shape almost everything else about the system. Federation decides who can bring an existing identity to your application. User stores decide who owns the canonical record once they arrive.

Identity Federation

External identity providers, both social and enterprise, let users bring an identity they already have to your application, instead of managing a separate credential. Done well, federation creates one user record per real person regardless of how many sign-in methods they end up using. Most consumer apps adopt at least one social provider (Google, GitHub, and similar), and prosumer apps add enterprise sign-in through OpenID Connect.

There are three main questions that need to be decided here. How does a user record come into existence the first time someone federates in, and how does a second sign-in method attach to a person who already has one, and does signing out of your application also end that user's ThunderID session, so a returning visit requires federating in again?

Just-in-Time Provisioning

The first time someone signs in through a provider, no local record exists for them. Just-in-time provisioning creates one on the spot from whatever the provider returns, so the person gets in without filling out a registration form.

The alternative is to require the record first. Someone invites, imports, or pre-registers the person, or the person has to create the account by any other means, and federation only signs in people who are already known. Most consumer apps want the open path. Apps with a paid tier, a waitlist, or a closed beta usually want the gated one, and plenty want both, open for Google and gated for the enterprise provider.

Provisioning also decides what the new record starts with. A provider usually hands back an email address and a display name, sometimes a picture. Anything else, a country or a marketing opt-in, has to come from the user after the sign-in. There is another decision to be made here, whether later sign-ins refresh those attributes, or the local copy is preserved after it is made, or a mix of these.

Account Linking

Account linking stops different authenticators creating different identities for one person. So a user who logs in with email password, Google and GitHub is treated as one person rather than having three different user accounts.

There are two ways to handle a sign-in that matches an existing account:

Verified linking: the provider returns a detail that matches an existing account, usually an email address, and the person is asked whether to link the two. If they agree, they prove they own the existing account by signing in to it with any method it already supports, such as a password, a one-time code, or another connected provider. Only then is the link made. A match alone never links accounts, so a provider that lets anyone claim any email address can't hand over someone else's account.
No linking: every provider identity stays its own record. Simple, and fine when those identities really are separate people. Might result in user confusion.

A person who declines to link continues with a separate account. That account can't reuse a detail that must be unique, so when email addresses are unique, a separate account with the same email address can't be created.

Unlinking deserves the same attention. Decide whether a person can detach a provider themselves, and what happens if they detach the last sign-in method they have.

Federation can also drive authorization, not just sign-in. An administrator can map attribute values a provider asserts, such as group membership, to local roles, groups, or permissions, so a user's access follows their standing at the provider without being administered a second time inside ThunderID. This also covers users with no local record at all, seeding a new hire's starting access at account creation, and delegating the decision to an external policy engine when your organization already has one. See Federated Attribute Mapping for the full pattern.

User Stores

Where consumer identities live affects sign-in performance, recovery options, federation behavior, and migration paths. Most consumer apps run a directly-managed user directory inside the identity product. The other option is no local record at all, relying entirely on federation for identity.

The choice comes down to who owns the canonical record. A directly-managed directory gives you the most features and the simplest operational model: profile attributes, credentials, and recovery state all live in one place. Relying entirely on federation removes that local record, at the cost of depending on the federated provider staying available and accurate for every sign-in.