Skip to content
Introducing the next era of Duende IdentityServer. Read our CEO’s announcement

Configuration Data

Configuration data models the information for Clients and Resources.

Store interfaces are designed to abstract accessing the configuration data. The stores used in Duende IdentityServer are:

Custom implementations of the stores must be registered in the ASP.NET Core service provider. There are convenience methods for registering these. For example:

Program.cs
builder.Services.AddIdentityServer()
.AddClientStore<YourCustomClientStore>()
.AddCorsPolicyService<YourCustomCorsPolicyService>()
.AddResourceStore<YourCustomResourceStore>()
.AddIdentityProviderStore<YourCustomIdentityProviderStore>();

Configuration data is used frequently during request processing. If this data is loaded from a database or other external store, then it might be expensive to frequently re-load the same data.

Duende IdentityServer provides convenience methods to enable caching data from the various stores. The caching implementation is built on Microsoft’s HybridCache from the Microsoft.Extensions.Caching.Hybrid package, registered as a keyed service under ServiceProviderKeys.ConfigurationStoreCache. For example:

Program.cs
builder.Services.AddIdentityServer()
.AddClientStore<YourCustomClientStore>()
.AddCorsPolicyService<YourCustomCorsPolicyService>()
.AddResourceStore<YourCustomResourceStore>()
.AddInMemoryCaching()
.AddClientStoreCache<YourCustomClientStore>()
.AddCorsPolicyCache<YourCustomCorsPolicyService>()
.AddResourceStoreCache<YourCustomResourceStore>()
.AddIdentityProviderStoreCache<YourCustomIdentityProviderStore>();

For Entity Framework users, there is a convenience method AddConfigurationStoreCache() that enables caching for all configuration stores at once:

Program.cs
builder.Services.AddIdentityServer()
.AddConfigurationStore(...)
.AddConfigurationStoreCache();

The duration of the data in the default cache is configurable on the IdentityServerOptions. For example:

Program.cs
builder.Services.AddIdentityServer(options => {
options.Caching.ClientStoreExpiration = TimeSpan.FromMinutes(5);
options.Caching.ResourceStoreExpiration = TimeSpan.FromMinutes(5);
})
.AddClientStore<YourCustomClientStore>()
.AddCorsPolicyService<YourCustomCorsPolicyService>()
.AddResourceStore<YourCustomResourceStore>()
.AddInMemoryCaching()
.AddClientStoreCache<YourCustomClientStore>()
.AddCorsPolicyCache<YourCustomCorsPolicyService>()
.AddResourceStoreCache<YourCustomResourceStore>();

Further customization of the cache is possible:

  • The caching stores use a keyed HybridCache instance registered under ServiceProviderKeys.ConfigurationStoreCache. You can customize the HybridCache behavior by configuring the keyed service registration (e.g., adding a distributed cache backend via IDistributedCache).
  • By default, only the L1 (in-memory) cache tier is used. To enable L2 (distributed) caching, register an IDistributedCache implementation (e.g., Redis via AddStackExchangeRedisCache). HybridCache will automatically use it as the L2 tier.

The various in-memory configuration APIs allow for configuring IdentityServer from an in-memory list of the various configuration objects. These in-memory collections can be hard-coded in the hosting application, or could be loaded dynamically from a configuration file or a database. By design, though, these collections are only created when the hosting application is starting up.

Use of these configuration APIs are designed for use when prototyping, developing, and/or testing where it is not necessary to dynamically consult database at runtime for the configuration data. This style of configuration might also be appropriate for production scenarios if the configuration rarely changes, or it is not inconvenient to require restarting the application if the value must be changed.