IdentityServer Spaces

A space is an isolated IdentityServer environment within one application deployment. Each space has its own configuration and operational data, while the application shares the same process, code and database infrastructure.

Use Spaces when you need to host multiple security domains without operating a separate IdentityServer deployment for each one. Examples include software-as-a-service tenants, regional environments or independently administered business units.

How Spaces Isolate Data

Spaces build on the pooled storage model in Duende Storage. Each space maps to a storage pool, a logical partition within the same database identified by a numeric pool ID. This isolates all configuration and operational data for that space. IdentityServer resolves the current space at the start of a request and routes all subsequent store operations to that pool.

The reserved management pool is separate from every pool that holds IdentityServer data. It stores each space definition, including its matching rules and assigned data pool. The default space uses data pool 0, while configured spaces normally use positive pool IDs. Normal IdentityServer requests never use the management pool as their data pool.

flowchart LR
    admin["ISpaceAdmin"] --> management["Reserved management pool"]
    management --> definitionA["Space A definition"]
    management --> definitionB["Space B definition"]
    default["Default space"] --> pool0["Data pool 0"]
    definitionA --> pool1["Data pool 1"]
    definitionB --> pool2["Data pool 2"]

Use ISpaceAdmin from a protected administration path to create spaces or change their pool assignments. Moving a space to another pool changes which data it sees, so authorize and audit these operations as changes to a security boundary.

How Spaces Resolve Incoming Requests

A space can match an incoming request by:

• Origin, such as https://tenant.example.com
• Path segment, such as /acme under the default /t prefix
• Both origin and path

Origin claims take precedence so a path cannot route a request away from a space that owns the host. With the default prefix, a space whose path is /acme receives requests under /t/acme. Middleware moves /t/acme to PathBase before ASP.NET Core routing, leaving the remaining path for IdentityServer endpoints.

Requests that explicitly use the space path prefix but do not match a space receive 404 Not Found. By default, other unmatched requests also receive 404 Not Found; you can opt into the default space with FallbackToDefault.

Caution

Only enable FallbackToDefault when serving an unmatched host or path from the default space is an intentional part of your isolation model. A strict 404 Not Found response is safer for multi-tenant deployments.

Leave IssuerUri unset with Spaces

Spaces rely on IdentityServer inferring the issuer from each request’s origin and path base, which is what gives every space its own iss claim. Leave IssuerUri unset so each space has its own issuer. Setting a fixed value makes every space return the same issuer/iss, although their data and normal OpenID Connect discovery endpoints remain separate. See Multi-Issuer for how issuer inference works.

UI and Application Services

Spaces use the same login, consent, logout and error page implementations. Space resolution runs before ASP.NET Core routing and path-based resolution moves the matched prefix into PathBase. The shared UI routes therefore run within the resolved space and read that space’s configuration and operational stores.

Spaces do not add per-space UI code or branding. To vary UI behavior, inject ISpaceContextAccessor into a scoped UI service, read the resolved SpaceId and load your own space-aware settings. Apply the same pattern to custom services that need space-specific behavior.

User databases and other application-level services are not made space-aware automatically unless they use the shared IStorageFactory. You must isolate or partition them separately when users, profile data, email delivery or other dependencies belong to a specific space.

Duende User Management

Duende User Management uses the same storage factory as IdentityServer. When Spaces is enabled, User Management data is routed to the resolved space’s pool by default. This isolates user profiles, authenticators, roles and groups per space.

If users must be shared across spaces, use a deliberately separate user directory architecture rather than the default space-aware User Management storage.

What Spaces Does Not Isolate

Spaces Do Not Isolate Process-Level Dependencies

Spaces isolate persisted data, but they do not automatically isolate every process-level dependency. Review signing credentials, ASP.NET Core Data Protection, external caches, telemetry, rate limits and custom services to decide whether they also need space-aware configuration.

For example, sharing signing credentials reduces cryptographic separation between spaces. Token validation still checks the issuer, audience and other constraints, but each space should use deliberately scoped credentials when your security model requires independent trust boundaries.

Your administration system must authorize operators for the specific spaces they manage. Never trust a space identifier supplied by a client without allowing the resolution middleware to validate it against a configured match pattern.

Getting StartedConfigure storage, add space resolution and create an initial space.

Duende StorageUnderstand the storage provider and its preview status.

Spaces SamplesExplore runnable samples for multi-space IdentityServer deployments.