This question relates to JwtBearer token configuration on a .Net Core API project.
Recently a colleague of mine updated Identity Server 4 to v4 and as a result, there were some breaking changes to the way tokens were supplied, most importantly the removal of the aud
(audience) element in the token (ref: IDS4 docs).
I was advised to configure the following in an ASP.Net Core API Startup.cs, and I added additional checks of the token header (ValidTypes check) and Key, which had been tested by the previous use of an '.AddIdentityServerAuthentication(options => ...)
' configuration.
services.AddAuthentication(
options =>
{
options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
}
)
.AddJwtBearer("Bearer",
options =>
{
options.Authority = "https://<<my_identity_server.com>>";
options.RequireHttpsMetadata = true;
options.TokenValidationParameters = new TokenValidationParameters()
{
ValidateAudience = false,
ValidTypes = new[] { "at+jwt" },
ValidateIssuerSigningKey = true,
IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("<<key/secret>>")),
};
});
Without these TokenValidationParameters settings, especially the 'ValidateAudience = false
', I get errors related to an empty audience ("The audience 'empty' is invalid"), so I have some confidence that these settings are being read and applied to some extent. However, if I change the correct expected header type ("at+jwt") or my key/secret value to an incorrect value, no errors result, and the API continues to returns results calls in to it. I have also attempted to add many TokenValidationParameter setting such as ValidateIssuer and ValidIssuer also without triggering errors on mismatch.
What am I missing that might be preventing these items from being tested properly?
I believe I have found out a fairly conclusive answer to the tests of the 'ValidTypes' value which triggered this question. The answer was found in the updated IDS4 docs, where there is a comment:
"On .NET Core 3.1 you need to manually reference the System.IdentityModel.Tokens.Jwt Nuget package version 5.6 to be able to check the type header."
Sure enough, this is a .Net Core 3.1 project, and after installing the System.IdentityModel.Tokens.Jwt package (currently at v6.8.0) I can get tests to auth to fail when I put a 'bad' expected value in the TokenValidationParameters, and then the local logs show errors such as:
info: Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler[7] Bearer was not authenticated. Failure message: IDX10257: Token type validation failed. Type: 'at+jwt'. Did not match: validationParameters.TokenTypes: '*****NOT_MY_JWT_HEADER_TYP*****'.
Correcting the expected ValidTypes to ValidTypes = new[] { "at+jwt" }
now works.
I'm really baffled how one is meant to discover things like this with middleware; it wasn't that I did not have the right version of the package... I did not have the package installed at all! I find it confusing.
I also mentioned in the question that I had tried to force failures by setting a bad expectation for a symmetric key value... but my api calls were not failing. I am less certain about this, but it turns out my colleague had decided to change the hashing of the JWT to use an asymmetric key. Thus, I would speculate that some part of the middleware was ignoring the symmetric key I was setting, as it identified that a different type of algorithm was in use on the token?