IDX10503: Signature validation failed. The token's kid is: '2026-10', but did not match any keys in TokenValidationParameters or Configuration.

Der vollständige Text geht mit „Keys tried: …“, Schlüsselanzahlen und Platzhaltern `[PII of type … is hidden]` weiter (setze in der Entwicklung `IdentityModelEventSource.ShowPII = true`, um sie zu sehen). Geprüft mit 6.36.0, 7.7.1 und 8.23.0: 6.x formuliert „IDX10503: Signature validation failed. Token does not have a kid. Keys tried: …“; 7.x und 8.x verwenden den Wortlaut oben und melden ein Token ohne `kid` als IDX10517 „The token's kid is missing“.

Microsoft.IdentityModel.JsonWebTokens / System.IdentityModel.Tokens.Jwt (.NET) — SecurityTokenSignatureKeyNotFoundException

Was der Fehler bedeutet

Das Token nennt seinen Signaturschlüssel über einen `kid`, und kein Schlüssel in `TokenValidationParameters` (`IssuerSigningKey(s)`) oder in der aus dem JWKS der Authority heruntergeladenen Konfiguration hat diese Schlüssel-ID. Die Signatur wurde nie berechnet – es gab keinen infrage kommenden Schlüssel. In ASP.NET Core sieht der Client `WWW-Authenticate: Bearer error="invalid_token", error_description="The signature key was not found"`.

Warum der Fehler auftritt

• Der Aussteller hat seinen Signaturschlüssel rotiert

  häufig

  Ein statisch konfigurierter Schlüssel (oder eine zwischengespeicherte Konfiguration, die nie aktualisiert wurde) kennt nur den vorherigen `kid`. Entra ID, Auth0, Keycloak und IdentityServer rotieren alle ihre Schlüssel.

• Authority oder Metadatenadresse eines anderen Mandanten

  häufig

  v1- vs. v2-Endpunkte von Entra ID, eine andere Mandanten-ID, B2C-Richtlinien mit eigenen Metadaten oder eine Staging-Authority. Die heruntergeladenen Schlüssel sind gültig – für die Tokens von jemand anderem.

• Die Konfiguration konnte nicht geladen werden

  gelegentlich

  Schlägt der Download der Metadaten fehl, validiert der Handler mit null Schlüsseln aus der Konfiguration („Number of keys in Configuration: '0'“). Der eigentliche Fehler (IDX20803) wird separat geloggt.

• Ein einzelner IssuerSigningKey für einen Aussteller mit mehreren Schlüsseln

  gelegentlich

  Einen Schlüssel aus dem JWKS fest im Code zu hinterlegen, funktioniert nur so lange, bis der Aussteller mit einem anderen Schlüssel aus dem Set signiert.

So behebst du den Fehler

1. 1.

   Schlüssel vom Handler bei der Authority abrufen lassen

   Ist `Authority` gesetzt, lädt `JwtBearer` das JWKS des Ausstellers über OpenID Connect Discovery herunter und aktualisiert es regelmäßig sowie zusätzlich dann, wenn ein Token einen unbekannten Schlüssel nennt (`RefreshOnIssuerKeyNotFound`, standardmäßig aktiv).

   builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
       .AddJwtBearer(options =>
       {
           // Keys come from {Authority}/.well-known/openid-configuration -> jwks_uri and are refreshed automatically.
           options.Authority = "https://login.example.com/";
           options.Audience = "api://orders";
       });

2. 2.

   Verborgene Werte beim Debuggen sichtbar machen

   IdentityModel verbirgt Schlüssel-IDs und Token-Inhalte im Text von Exceptions standardmäßig. Aktiviere `ShowPII` nur in der Entwicklung, um zu sehen, welche Schlüssel probiert wurden.

   // Development only: show the hidden values ([PII of type ... is hidden]) in IDX messages.
   if (builder.Environment.IsDevelopment())
   {
       Microsoft.IdentityModel.Logging.IdentityModelEventSource.ShowPII = true;
   }

← Gesamte Signaturfehler-Datenbank durchsuchen