Help us make content visible
Search terms used: IssuerSigningKeyResolver aspnetcore, JwtBearer custom signing key, multi-tenant JWT validation aspnetcore.
Docs found that didn't address the concern:
Describe the new topic
Why it's needed
TokenValidationParameters.IssuerSigningKeyResolver is the standard extension point for dynamic signing-key lookup (multi-tenant apps, JWKS caching, custom key stores, key-rotation rollouts). It's widely used in real-world apps but has no official sample. Developers searching for examples land on third-party blogs and Stack Overflow, where anti-patterns are common.
The risk is concrete: ASP.NET Core's default JwtBearer config defends against HS/RS algorithm-confusion attacks via typed-key resolution — JsonWebTokenHandler only verifies HS256 signatures with SymmetricSecurityKey candidates. A custom resolver that returns a SymmetricSecurityKey derived from public-key bytes (a plausible mistake when caching key material in a multi-tenant scenario) silently disables that defense. The same forged HS256 token that the default config rejects with 401 then validates with 200 OK and full claim assumption.
I have a self-contained reproduction (Minimal API + xUnit, runs dotnet test in under 2 seconds) demonstrating both the safe default and the broken-resolver attack:
https://github.com/loganbryanx/aspnetcore-auth-lab
Suggested ToC location
fundamentals/security/authentication/configure-jwt-bearer-authentication — as a new sibling page or expanded section titled "Custom signing-key resolution".
Abstract
A how-to for implementing IssuerSigningKeyResolver in scenarios that aren't covered by Authority-based discovery (multi-tenant apps, custom key stores, advanced JWKS caching). Side-by-side examples show a safe resolver that asserts key/algorithm compatibility before yielding keys, and an anti-pattern resolver that silently disables the framework's typed-key defense against HS/RS algorithm confusion. Includes the recommendation to set ValidAlgorithms as defense-in-depth.
Outline
- When you need a custom resolver (and when you don't — prefer
Authority if possible)
- The safe pattern — minimal multi-tenant resolver, with
kid-keyed lookup
- JWKS caching with
IssuerSigningKeyResolverUsingConfiguration
- The anti-pattern — wrapping public-key bytes in
SymmetricSecurityKey, with the algorithm-confusion risk it introduces
- Defense in depth — setting
ValidAlgorithms, asserting key types, logging on validation failure
- Testing your resolver — a forged-token regression test pattern
Happy to draft the PR if the team agrees the gap warrants it.
Help us make content visible
Search terms used:
IssuerSigningKeyResolver aspnetcore,JwtBearer custom signing key,multi-tenant JWT validation aspnetcore.Docs found that didn't address the concern:
Authority/IssuerSigningKeybut not custom resolvers.dotnet/AspNetCore.Docsreturns 0 hits forIssuerSigningKeyResolver. The same query ondotnet/aspnetcorealso returns 0. The only hits across thedotnetorg are inside the IdentityModel implementation itself — there is no narrative guidance on how to implement this extension point safely.Describe the new topic
Why it's needed
TokenValidationParameters.IssuerSigningKeyResolveris the standard extension point for dynamic signing-key lookup (multi-tenant apps, JWKS caching, custom key stores, key-rotation rollouts). It's widely used in real-world apps but has no official sample. Developers searching for examples land on third-party blogs and Stack Overflow, where anti-patterns are common.The risk is concrete: ASP.NET Core's default JwtBearer config defends against HS/RS algorithm-confusion attacks via typed-key resolution —
JsonWebTokenHandleronly verifies HS256 signatures withSymmetricSecurityKeycandidates. A custom resolver that returns aSymmetricSecurityKeyderived from public-key bytes (a plausible mistake when caching key material in a multi-tenant scenario) silently disables that defense. The same forged HS256 token that the default config rejects with 401 then validates with 200 OK and full claim assumption.I have a self-contained reproduction (Minimal API + xUnit, runs
dotnet testin under 2 seconds) demonstrating both the safe default and the broken-resolver attack:https://github.com/loganbryanx/aspnetcore-auth-lab
Suggested ToC location
fundamentals/security/authentication/configure-jwt-bearer-authentication— as a new sibling page or expanded section titled "Custom signing-key resolution".Abstract
A how-to for implementing
IssuerSigningKeyResolverin scenarios that aren't covered byAuthority-based discovery (multi-tenant apps, custom key stores, advanced JWKS caching). Side-by-side examples show a safe resolver that asserts key/algorithm compatibility before yielding keys, and an anti-pattern resolver that silently disables the framework's typed-key defense against HS/RS algorithm confusion. Includes the recommendation to setValidAlgorithmsas defense-in-depth.Outline
Authorityif possible)kid-keyed lookupIssuerSigningKeyResolverUsingConfigurationSymmetricSecurityKey, with the algorithm-confusion risk it introducesValidAlgorithms, asserting key types, logging on validation failureHappy to draft the PR if the team agrees the gap warrants it.