Azure-activedirectory-identitymodel-extensions-for-dotnet: Expiration date is limited to Tue, 19 Jan 2038 03:14:07 GMT

[wvdd007]

I was using the version 0.1.0 of the nuget up until now. We are switching to the new nuget. To make sure that everything which worked before still works, I wrote some regression tests. One of them is "a token that was valid using the old handler should still be valid". To be able to test this, a serialized tons of jwt tokens using all of my RP settings and created a fake token with an expiration date at new DateTime(4321, 1, 1). (To be easy to visually see if it is correct) To my surprise this test failed with the current implementation. "IDX10225: Lifetime validation failed. The token is missing an Expiration Time.". I reverified my token which had ""nbf":0,"exp":74190380400". After a debugging session I noticed that there was an overflow exception (which is eaten by the handler). I saw that the claim is read using an int32. In practical situations this might be enough but I would have preferred the usage of an int64 for this. What do you think ?

[brentschmaltz]

I used int32 as it maps nicely to epoch time. You are correct that in 2038, it wraps.
I think it is worth consideration.

[wvdd007]

In theory this is a detail. In practice, we've had the fuzz about Y2K and we somehow would avoid something similar (although I fully admit that 2038 is still a lot of time). It's up to you what you do with it.

[tushargupta51]

Closing this issue for now, 2038 is way in the future. We can revisit this later.

[MarkDuckworth]

This is still a bug, please reopen.

[silverferrum]

This is still a bug, please reopen. (2)

[brentschmaltz]

@silverferrum Changing JwtPayload.Exp to long? would be breaking and would cause problems for many users.

We could add a new property that returns long?
We are favoring JsonWebToken and when we add the Exp property, we will add it as a long?.

[silverferrum]

@brentschmaltz hi!
Problem is that if we specify expiration after 2038-1-19 the token will be generated with correct exp value. But when we attempt to validate such token the error will be returned in header
www-authenticate: Bearer error="invalid_token", error_description="The token has no expiration"

So I cannot advise you how to fix that because I do not use JwtPayload.Exp property directly but the AuthorizeAttribute does.

[brentschmaltz]

@silverferrum I am curious why you need a date so far in the future?

Can you share how you are using the AuthorizeAttribute?

[silverferrum]

Currently, it is not creating a bug for me but it is weird that token is generated with correct expiration but can't validate it.
Is it really hard to fix?

        public static void AddJwtAuthentication(this IServiceCollection services, IConfiguration configuration)
        {
            var jwtOptions = new JwtOptions();
            configuration.GetSection("JwtOptions").Bind(jwtOptions);

            services.Configure<JwtOptions>(o =>
            {
                o.Key = jwtOptions.Key;
                o.Issuer = jwtOptions.Issuer;
                o.Audience = jwtOptions.Audience;
            });

            var tokenValidationParameters = new TokenValidationParameters
            {
                ValidateIssuer = true,
                ValidateAudience = true,
                ValidateLifetime = true,
                ValidateIssuerSigningKey = true,
                ValidIssuer = jwtOptions.Issuer,
                ValidAudience = jwtOptions.Audience,
                IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(jwtOptions.Key))
            };

            services
                .AddAuthentication(o =>
                {
                    o.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
                    o.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
                })
                .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options =>
                {
                    options.TokenValidationParameters = tokenValidationParameters;
                });
        }

And then you just add the AuthorizeAttribute to the ASP.NET Core Controller.

[brentschmaltz]

@silverferrum the problem is the api returns an int (our mistake). If we change it to return a long we will break users. That is why we would need a new API. Breaking users is a really bad thing in today's world of multiple dependencies.

[silverferrum]

I think you are right. Maybe, adding the long field with marking the int field as obsolete will be good idea for a couple of years.