User Store Or Federation: Choosing The Right Identity Source

Not every customer is ready for enterprise single-sign-on on day one.

Some customers arrive with a mature identity team, an OpenID Connect or ADFS setup, approval processes, and a clear policy that every business application must use the corporate directory. Others are earlier in their journey. They may be a new subsidiary, a pilot team, a smaller customer, or an organization that wants to start using the SaaS application before its central IT team has completed the federation work.

That difference matters. If the SaaS product only supports federation, onboarding waits for the customer’s IdP project. If it only supports local accounts, enterprise customers have to duplicate users, passwords, groups, and lifecycle processes outside their own directory.

The better model is to support both: a managed user store for customers that need a quick start, and federation for customers that want their own directory to remain the source of authentication.

Two valid onboarding models

In ProAuth, applications keep a single trust relation to ProAuth. Behind that boundary, each tenant can use the identity source that fits its situation: a ProAuth User Store instance, a federated customer identity provider, or a planned transition from one to the other.

That distinction keeps customer maturity out of application code. The application still validates tokens from ProAuth and consumes the same application-facing identity contract. The tenant-specific authentication choice stays in the identity layer.

flowchart TD
    start["New customer onboarding"]
    enterprise["Customer has a managed enterprise IdP?"]
    ready["IdP team can complete setup before go-live?"]
    lifecycle["Customer wants central password, MFA, and lifecycle ownership?"]
    userstore["Start with a ProAuth User Store<br/>managed users and groups"]
    federation["Configure a tenant-specific federated IdP instance"]
    hybrid["Use User Store for launch<br/>plan federation for selected tenants"]
    scim["Add provisioning when users and groups must exist before login"]

    start --> enterprise
    enterprise -->|"No"| userstore
    enterprise -->|"Yes"| ready
    ready -->|"No"| hybrid
    ready -->|"Yes"| lifecycle
    lifecycle -->|"Yes"| federation
    lifecycle -->|"Not yet"| userstore
    federation --> scim
    hybrid --> federation

The decision is less about protocol preference than operating model. Who owns the users? Who resets access? Who decides when an employee leaves? Who needs to approve the login policy? Those questions usually make the right identity source obvious.

When the User Store is the right start

A User Store is useful when the SaaS team or tenant administrator needs to manage access directly in ProAuth. It works well when the customer does not yet have an enterprise IdP ready, when a pilot must start quickly, or when the user population is intentionally local to the application.

ProAuth models the User Store as an IdP instance. It can be assigned to the required tenants and configured with its own connection string, callback path, claim issuer, mail settings, password behavior, and other options. The User Store stores credentials, so it should be chosen deliberately. That is also its strength: the login path can exist without waiting for an upstream directory.

The practical benefits are straightforward:

• user and group management can happen inside ProAuth
• tenant administrators can onboard users without coordinating an external IdP project first
• the SaaS team can control the initial lifecycle for smaller customers or pilots
• User Store users and groups can be synchronized into ProAuth users and groups for central role and MFA assignment

This is often the right starting point for customer onboarding. It reduces the first barrier to value. The customer can start using the application, learn which groups and roles it really needs, and involve its identity team once the rollout is proven.

When federation should be the default

Federation is the better choice when the customer already has an identity provider that is meant to control business application access.

In that model, ProAuth does not become the place where the customer’s passwords live. The customer authenticates users in its own directory, and ProAuth federates the result into the SaaS application. ProAuth supports tenant-specific IdP instances, so Customer A can authenticate through its directory while Customer B uses a different provider, without either tenant seeing the other’s configuration.

Federation is usually the right answer when the customer needs:

• enterprise single-sign-on with its existing directory
• customer-owned password, MFA, and access policies
• central joiner, mover, and leaver processes
• a clear separation between SaaS application ownership and corporate identity ownership
• tenant-specific routing to the customer’s selected IdP

This is the model many enterprise customers expect. It lets their identity team keep the controls they already operate, while the SaaS application continues to trust ProAuth as the single issuer.

Directory provisioning is a separate question

Federation proves who the user is at login time. It does not automatically mean the application knows about every user before the first login.

That distinction matters for enterprise products. If the application needs to assign owners, approvers, permissions, or comments to users who have not logged in yet, a pure login-time model is not enough. ProAuth supports SCIM for this reason. Each OIDC IdP instance can have its own SCIM endpoint, so user and group provisioning can be tied to the tenant-specific federation configuration.

This is where the onboarding conversation should be precise:

• If users only need access when they first arrive, federation with automatic ProAuth user creation may be enough.
• If users and groups must exist before first login, plan provisioning.
• If the customer synchronizes users and groups through SCIM, disable automatic user creation for that IdP so unexpected directory users cannot create ProAuth users just by logging in.

Those details are easy to miss when “SSO” is treated as one requirement. In practice, authentication, user lifecycle, group lifecycle, and application authorization are separate decisions that meet in the identity layer.

A hybrid path is often the most realistic one

Many SaaS teams do not need to force every tenant into the same identity source from day one.

A smaller customer may stay on a User Store for a long time because it fits their operating model. A larger customer may start with a User Store during a pilot and later move to federation once procurement, IT security, and directory ownership are clear. Another customer may use federation for employees and a separate controlled path for support or operational users.

The important part is to make the transition explicit. Before the first enterprise customer asks for federation, decide:

• Which identifier will remain stable when moving from local users to federated users?
• Which user profile fields are owned by ProAuth, and which are owned by the customer’s directory?
• Which groups are application groups, and which groups should come from the customer directory?
• Will the customer need SCIM provisioning before first login?
• Which tenant-specific IdP instance owns the future login path?
• How will the application test that roles, groups, and claims still produce the same authorization outcome?

If those questions are answered early, the User Store does not become a dead end. It becomes an onboarding option that can coexist with federation.

Choose based on ownership, not only convenience

The simplest rule is this: use the User Store when ProAuth should own the local authentication lifecycle for that tenant. Use federation when the customer should own authentication through its existing identity provider.

Convenience matters, especially during onboarding, but ownership matters more. A User Store can make the first rollout easier. Federation can make the long-term enterprise operating model cleaner. ProAuth supports both patterns so the SaaS platform can meet customers where they are without pushing identity complexity into application services.

For configuration details, see the ProAuth documentation for User Store and Federated Identity Providers. For the broader tenant routing model, see How we identify tenants to provide a tailored authentication experience.