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 app. 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 app, removing the need to manage 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, and prosumer apps add enterprise OIDC.

Federation requires a few specific decisions. Should a user record be created the first time someone signs in via a provider (just-in-time provisioning), or only after an invitation? Should multiple federated identities link to one user, and what is the linking signal (verified email, explicit linking, or both)? Should signing out of your app sign the user out of the federated provider too? Should a user be routed to a specific provider automatically based on their email domain? Each of these is configurable independently.

Capabilities Involved:

Social sign-in via Google, GitHub, and other social providers.
Enterprise sign-in via OpenID Connect.
Just-in-time (JIT) provisioning: create the user the first time they sign in this way.
Single logout (SLO): sign the user out of every place they're signed in.
Account linking: connect multiple sign-in methods to a single user.
Home-realm discovery: route the user to the right provider based on their email domain.

User Stores

Where consumer identities live affects everything else: sign-in performance, recovery options, federation behavior, and migration paths. Most consumer apps run a directly-managed user directory inside the identity product. Other options are no local record at all (relying entirely on federation), an existing directory you own (LDAP or a custom backing store), or a mix.

The choice often comes down to source of truth: who owns the canonical user record. If the identity product owns it, you get the most features and the simplest operational model. If an external system owns it, you get integration with existing data flows and a single source of truth across the business. The trade-off is less flexibility on the identity side. A mixed deployment lets you move identities between stores at your own pace. This is useful during migrations or when different user segments have different requirements.

Capabilities Involved: