Validating tokens using TokenValidationParameters.ConfigurationManager

Support for validating tokens by simply providing an authority address has been recently added to the JsonWebTokenHandler. This feature will soon be coming to the JwtSecurityTokenHandler as well.

Rather than providing the issuer and signing keys directly on the TokenValidationParameters, users can now create a ConfigurationManager object with the relevant authority and set it on the TokenValidationParameters.ConfigurationManager property. During the validation flow, this ConfigurationManager will be used to retrieve the metadata corresponding to the provided authority.

Note that the type of TokenValidationParameters.ConfigurationManager is BaseConfigurationManager, which is designed with extensibility in mind so that you can implement your own ConfigurationManager if need be.

Resiliency is baked into this feature, another attempt to obtain the metadata will be triggered if:

• There was a network failure
• If signing key was not found in the configuration being used for validation and the token is valid (such as issuer and more) and not expired.

The library also keeps track of the Last Known Good (LKG) Configuration [TODO: add separate page on how the LKG feature works], which is the Configuration that was last used to successfully validate an incoming token.

The following code snippet showcases how to make use of this feature. See Validating Tokens for more information on the validation process in general.

var configurationManager = new ConfigurationManager<OpenIdConnectConfiguration>("myauthority.com", new OpenIdConnectConfigurationRetriever(), new HttpDocumentRetriever());
validationParameters.ConfigurationManager = configurationManager;
var jsonWebTokenHandler = new JsonWebTokenHandler();
var tokenValidationResult = jsonWebTokenHandler.ValidateToken(token, validationParameters);
if (!tokenValidationResult.IsValid)
{
   // Handle each exception which tokenValidationResult can contain as appropriate for your service
   // Your service might need to respond with a http response instead of an exception.
   if (tokenValidationResult.Exception != null)`
       throw tokenValidationResult.Exception;
    
   throw CustomException("");
}

It is possible to have successful token validation even if configuration retrieval fails, as the relevant issuer and signing key for token validation might be set on the TokenValidationParameters. Because of this, we do not throw exceptions related to metadata retrieval failure, but rather log them as information. In order to view potential configuration retrieval errors, you will need to set up logging for your service. Instructions for how to do that can be found here.

Some common errors you may see are:

• IDX10265 - Occurs when there was a network error that prevented us from obtaining the configuration on the first try. This will trigger another metadata poll.
• IDX10266 - Occurs when we are unable to obtain the configuration, but it's due to an HTTP error and we have information on the HTTP status code and HTTP response returned.
• IDX10261 - Occurs when we are unable to obtain the configuration, but it is not due to an HTTP error.

If you are having trouble debugging these errors and have the ability to do so, turning on PII may help you get enough information to figure out the source of your issues.