Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
213 views
in Technique[技术] by (71.8m points)

c# - JwtBearer TokenValidationParameters don't seem to be Tested

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?

question from:https://stackoverflow.com/questions/65916981/jwtbearer-tokenvalidationparameters-dont-seem-to-be-tested

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

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?


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...