Documentation is unclear about TokenValidationParameters.ValidateIssuerSigningKey

Opened at https://github.com/dotnet/core/issues/5877 by @marwalsch

I am setting up Basic AuthN for a JWT issued by the Windows STS. However, I am unsure about the correct way to do so and the Documentations are somewhat lacky about the correct way. These are my AddJwtBearer -options and the simplified Token:

options.TokenValidationParameters = new TokenValidationParameters  
                    {
                        ValidateIssuer = true,
                        ValidIssuer = "https://sts.windows.net/tenant/", 

                        ValidateAudience = true, 
                        ValidAudience = "api://domain.ngrok.io/resource",

                        ValidateIssuerSigningKey = true, 


                        ValidateLifetime = true
                    };
                    options.Audience = "api://domain.ngrok.io/resource";
                    options.Authority = "https://sts.windows.net/tenant/";

{
  "typ": "JWT",
  "alg": "RS256",
  "x5t": "nOo3ZDrODXEK1jKWhXslHR_KXEg",
  "kid": "nOo3ZDrODXEK1jKWhXslHR_KXEg"
}
{
  "aud": "api://domain.ngrok.io/resource",
  "iss": "https://sts.windows.net/tenant/",
  "iat": 1611134241,
  "nbf": 1611134241,
  "exp": 1611141741,
}
{<SIGNATURE>}

Validation works as far as to deprecated Tokens or those lacking a signature partition entirely being rejected. I am unsure about the most important step though, namely the Signature-Validation. The docs have these description for the cirresponding parameters:

Authority: “Gets or sets the Authority to use when making OpenIdConnect calls.” ValidateIssuerSigningKey: “Gets or sets a boolean that controls if validation of the SecurityKey that signed the securityToken is called. It is possible for tokens to contain the public key needed to check the signature. For example, X509Data can be hydrated into an X509Certificate, which can be used to validate the signature. In these cases it is important to validate the SigningKey that was used to validate the signature. This boolean only applies to default signing key validation. If IssuerSigningKeyValidator is set, it will be called regardless of whether this property is true or false.” (Link to the docs)

This sounds like the Middleware uses the Authority (“https://sts.windows.net/tenant/”) to retrieve the public key from the Windows STS and check the signature through the given alg-Parameter (RS256 in this case).

Is this correct? Or am I lacking additional configuration to achieve the desired? Many samples have an additional parameter passed to ValidIssuerSigninKey but i suppose this is unnecessary if my Token hails from the STS and not my own implementation.

EDIT: I am referring to .NET Core 3.1

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 42945161-9bd6-f8c0-ffda-b0fa03ec59fb
• Version Independent ID: 869eaee1-613a-b50a-0f18-8512dae792bd
• Content: TokenValidationParameters.ValidateIssuerSigningKey Property (Microsoft.IdentityModel.Tokens) - Azure for .NET Developers
• Content Source: xml/Microsoft.IdentityModel.Tokens/TokenValidationParameters.xml
• Service: active-directory
• GitHub Login: @CamSoper
• Microsoft Alias: casoper

[marwalsch]

@brentschmaltz Thanks but unfortunately, this description still doesn’t answer my question to full extend. It states: “Normally this is not required because the user / runtime must set IssuerSigningKey or IssuerSigningKeys or in the case of custom security key retrieval the delegate IssuerSigningKeyResolver […]”. But am I required to set a signing key? My token hails from Azure AD itself after all, and I expected the middleware to retrieve it by default. Please refer to this extract from my original question: “[…] am I lacking additional configuration to achieve the desired? Many samples have an additional parameter passed to ValidIssuerSigninKey but i suppose this is unnecessary if my Token hails from the STS and not my own implementation.”

With my current configuration, tokens that have a removed signature or some Base64-gibberish replacing it are rejected, but obviously I want to make sure that the actual signature is checked against with the public key correctly.

@jsquire Please re-open if necessary.

[marwalsch]

@allysonjoses Don’t quote me on that, but I’m am almost 100% sure that

• TokenValidationParameters.ValidIssuer merely checks for string equality;
• JwtBearerOptions.Authority actually does an OIDC compliant call to the well-known endpoint to validate the signature.