Duende IdentityServer Configuration
When to Use This Skill
Use this skill when:
- Setting up a new Duende IdentityServer host
- Defining or modifying client registrations
- Configuring API resources, API scopes, or identity resources
- Setting up signing key management (automatic or static)
- Enabling server-side sessions
- Tuning
IdentityServerOptionsfor production deployments - Migrating from IdentityServer4 to Duende IdentityServer
Core Principles
- Authorization Code + PKCE by Default — Use
GrantTypes.Codefor all interactive clients. Never use implicit flow for new applications. - Least Privilege Scopes — Grant clients only the scopes they need. Avoid wildcard or overly broad scope assignments.
- Automatic Key Management — Prefer the built-in automatic key rotation over static key configuration in production.
- API Resources for Audience Isolation — Use
ApiResourceto control theaudclaim and isolate API boundaries. UseApiScopefor fine-grained permission modeling within those boundaries. - Server-Side Sessions for Enterprise — Enable server-side sessions when you need centralized session management, back-channel logout, or session queries.
Related Skills
identityserver-stores— EF Core persistence for configuration and operational dataoauth-oidc-protocols— Protocol fundamentals that underpin these configuration choicesidentity-security-hardening— Production hardening of IdentityServer deploymentstoken-management— Client-side token lifecycle with Duende.AccessTokenManagementaspnetcore-authentication— Configuring OIDC authentication in client applications
Docs: https://docs.duendesoftware.com/identityserver/configuration
Sub-Documents
Load these sub-documents when the user's question specifically targets one of these areas:
Pattern 1: Hosting and Basic Setup
Register Duende IdentityServer in Program.cs with AddIdentityServer. All configuration flows from the IdentityServerOptions lambda and the builder's fluent API.
Important: Call
UseIdentityServer()instead ofUseAuthentication()— it registers both the IdentityServer middleware and the authentication middleware.
Pattern 2: Client Definitions
Clients represent applications that request tokens. The three most common configurations are:
Machine-to-Machine (Client Credentials)
For service-to-service communication with no interactive user:
Interactive Web Application (Authorization Code + PKCE)
For server-rendered web apps that authenticate users and call APIs:
SPA with BFF Pattern
For JavaScript SPAs using the Backend-for-Frontend pattern (see duende-bff skill):
Key Client Properties
Defining Clients in appsettings.json
For scenarios where client configuration should be externalized:
Pattern 3: Identity Resources
Identity resources define groups of claims about users, requested via the scope parameter. They map to claims in the identity token and the userinfo endpoint.
Standard Identity Resources
Custom Identity Resources
Define custom identity resources for application-specific user claims:
Key concept: The
openidscope is mandatory for any OpenID Connect request. It tells IdentityServer to return thesub(subject ID) claim.
Pattern 4: API Scopes and API Resources
API scopes and API resources work together to model your API surface area. Understanding the distinction is critical.
API Scopes — Permission Model
An ApiScope represents a permission or capability a client can request:
API Resources — Logical API Boundaries
An ApiResource represents a logical API (typically a deployed service). It groups scopes and controls the aud (audience) claim in access tokens:
When to Use ApiResource vs ApiScope
Resource Isolation
When multiple APIs share scope names, resource isolation prevents a token issued for one API from being used at another:
With resource isolation, the client specifies the target resource in the token request using the resource parameter (RFC 8707), and IdentityServer issues a token with a single audience.
Pattern 5: Automatic Key Management
Duende IdentityServer's automatic key management handles signing key creation, rotation, and retirement. This is the recommended approach for production.
Key Lifecycle
Keys move through these phases:
- Announced — Added to discovery but not used for signing (
PropagationTimeduration) - Active — Used for signing tokens (until
RotationIntervalis reached) - Retired — No longer signs tokens, but remains in discovery for validation (
RetentionDuration) - Deleted — Removed from discovery (if
DeleteRetiredKeysis true)
Multiple Signing Algorithms
Support multiple algorithms for different clients or APIs:
The first algorithm in the list becomes the default. Clients and API resources can override via
AllowedTokenSigningAlgorithms.
Load-Balanced Deployments
For file-system key storage in load-balanced environments, all instances need access to the same key path:
Alternatively, use the EF Core operational store for database-backed key storage (see identityserver-stores).
Pattern 6: Static Key Configuration
When automatic key management is not available or you need explicit control:
Manual Key Rotation (Three-Phase Process)
Rotating static keys requires careful sequencing to avoid breaking token validation:
Pattern 7: Server-Side Sessions
Server-side sessions store authentication session data in a server-side store instead of the cookie alone. This enables centralized session management, queries, and back-channel logout.
Important: Server-side sessions are enabled by calling
.AddServerSideSessions()on the IdentityServer builder — there is nooptions.ServerSideSessions.Enabledproperty. Add this to the builder chain, not to options.
Session Expiration Options
Tip: Combine server-side sessions with
CoordinateClientLifetimesWithUserSession = trueto ensure refresh tokens are revoked when a user's session ends.


