Best approach for handling 100+ tenant RedirectUris under a single Client ID

[gauravsarwal]

Context:

We are running a multi-tenant application where the same web app code is deployed across ~100 distinct instances in IIS. Some tenants share a multi-tenant infrastructure, while others are entirely dedicated with their own separate databases. We are looking to implement Duende IdentityServer to handle OIDC and enable Single Sign-On (SSO) with another upstream service.

we intend to register all 100+ tenant instances under a single global ClientId (e.g., "robo-web").

We are considering grouping all tenant callback domains inside the RedirectUris and PostLogoutRedirectUris arrays for this single client, pulling the list dynamically from a database rather than hardcoding it:

new Client
{
    ClientId = "robo-web",
    AllowedGrantTypes = GrantTypes.Code,
    
    // Dynamically loaded from database (Contains 100+ items)
    RedirectUris = { 
        "https://robo.com",
        "https://robo.com",
        "https://owndomain.com",
        // ...90+ more domains
    },
    PostLogoutRedirectUris = { 
        "https://robo.com",
        "https://robo.com",
        "https://owndomain.com",
        // ...90+ more domains
    },
    AllowedScopes = { "openid", "profile", "api1" }
}

Questions / Points for Discussion

1. Security & Isolation: Does passing a massive global list of allowed redirect URLs to a single ClientId expose us to cross-tenant token substitution vulnerabilities? If a user initiates a login from ://robo.com but forces the redirect to ://robo.com, will IdentityServer allow it since both domains are "trusted" by the same client?

2. Performance: What are the performance and memory implications of loading and validating hundreds of custom tenant domains inside the Client object during the token pipeline?

3. Alternative Solutions: Is implementing a custom IRedirectUriValidator to lazily match the incoming domain against our database a safer and more performant pattern here? Alternatively, does this use case require something like the Duende "Spaces" add-on?

We want to make sure we architect this correctly for security, performance, and compliance with the 10 Client ID license boundary. Any recommendations or best practices from the team would be greatly appreciated!

[wcabus]

The most secure solution would be to assign a separate client ID per tenant, especially if you want to isolate scopes or sessions per tenant (e.g. when sending logout notifications). A single client ID for all tenant instances could work, but there are a few things to keep in mind. I'll try and answer your questions.

1. Security: can a redirect be switched to another tenant's domain?

In short: no. IdentityServer checks the redirect_uri against the client's allowed list on every authorize request, and the authorization code is bound to the redirect_uri it was issued for. When the code is redeemed, the token endpoint requires the exact same redirect_uri again: a code issued for tenant-a.com can't be redeemed with tenant-b.com.

The real risk here, is that all your tenant apps share one client, so they all accept the same tokens:

• Silent cross-tenant sign-in: a user signed in to tenant A who visits tenant B, gets signed in silently via SSO. There's no consent step or client boundary to stop this from happening.
• Token reuse across tenants: access tokens issued when signing in from tenant A have the same client_id, audience and scopes as tokens issued for flows initiated by tenant B.

If your tenants need to be isolated from each other, you need to add that isolation yourself (see Binding tokens to a tenant below) or make sure the client has a separate client ID for each tenant.

2. Performance

A few hundred redirect URIs compared by exact string match costs very little in terms of performance, especially when client store caching is enabled. Performance should likely not weigh in your decision.

3. Alternatives

Custom IRedirectUriValidator

A custom IRedirectUriValidator that checks the requested URI against your tenant registry is a reasonable approach. It isn't any safer or faster than a large list, but it keeps one source of truth for tenant hosts, which you'll likely want for the topics below too. Keep matching exact (scheme, host and path), with no wildcards or prefix matching.

Spaces

Spaces is our solution for making IdentityServer itself multi-tenant aware. From what you've described, the multi-tenancy is on the client side (one app deployed per tenant), with a single IdentityServer serving them all. That setup doesn't necessarily need Spaces.

It becomes relevant if IdentityServer also needs per-tenant behavior, such as separate users, signing keys, configuration or branding per tenant. If that's the case, let us know more about your IdentityServer setup and we can look at it together. For lighter-weight scenarios, a tenant hint passed via acr_values lets the login UI adapt to a tenant without full multi-tenancy; see also tenant hints versus Spaces.

Logout across 100+ tenants

The Client model has a single FrontChannelLogoutUri and a single BackChannelLogoutUri property. With one client, signing out by default only notifies one tenant URL when configured.

IdentityServer builds front- and back-channel logout notifications in ILogoutNotificationService, which you can replace. The difficulty is that a user's session only records which client IDs it signed in to, not which redirect URI (and therefore which tenant) was used. To notify every tenant, you'd need to:

• Record tenants per session: track which tenants each session (sid) has signed in to, for example from a custom authorize request validator once the user is authenticated.
• Expand the shared client at logout: have your logout notification service turn the shared client into one notification per tenant used in that session.
• Clean up: remove the relevant records when sessions end. Server-side sessions can help here.

Binding tokens to a tenant

To prevent the cross-tenant reuse described in question 1, consider parameterized scopes, such as tenant:acme. With a custom IScopeParser, a single registered tenant scope can carry the tenant as a parameter, and that value ends up in the issued access token.

The important part is that the server must enforce it. The client chooses which scopes to request, so the scope only binds anything if IdentityServer checks it. At minimum, verify that:

• the requested tenant matches the tenant that owns the redirect_uri, and
• the user actually belongs to that tenant.

On the receiving side:

• APIs should reject tokens that don't carry their own tenant scope.
• Web apps should check a tenant claim in the ID token, because scopes don't appear in ID tokens. You can add that claim through your profile service. This prevents a silent SSO sign-in from another tenant from becoming a local session.

An alternative is resource isolation using resource indicators, with an API resource per tenant, which puts the tenant in the token's audience. That also works, but means managing a large number of API resources.