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.

[stukselbax]

Today is 22.11.2021, problem still exist - System.IdentityModel.Tokens.Jwt, Version=6.14.1.0.

Please, introduce major release with Y2K fix.

One day the users with old version of this package will get broken application. That's sad.

[vcsjones]

A developer reported an issue to dotnet/runtime that was ultimately this issue. dotnet/runtime#63001 (comment)

[ggeurts]

This issue has cost me days of work trouble shooting. Please make the Int32 value obsolete and add an 64-bit version of the property that gets used by the validators.

[brentschmaltz]

@ggeurts ouch, that is painful.
Yes we will add a new API.

[andylai]

Is this issue has been solved? Or still the same?
I have faced this issue recently.
Any solution?
Thanks.

[brentschmaltz]

@andylai we haven't got to it yet.

[Exadra37]

On same boat here, spent some days trying to figure out what was wrong until I landed here.

[jaslam94]

The problem still exists.

[mus65]

For anyone who needs a workaround: we worked around this by setting TokenValidationParameters.RequireExpirationTime to false if exp overflows.

if (
  DateTime.UtcNow.Year < 2038 &&
  jwtTokenParsed.Payload.TryGetValue("exp", out object expObj) &&
  expObj is long exp &&
  exp > int.MaxValue
)
{
  requireExpirationTime = false;
}

[nikolaytashev]

I need this one fixed. The workarounds doesn't work for me.

[jhonathanc]

For anyone who needs a workaround: we worked around this by setting TokenValidationParameters.RequireExpirationTime to false if exp overflows.

if (
  DateTime.UtcNow.Year < 2038 &&
  jwtTokenParsed.Payload.TryGetValue("exp", out object expObj) &&
  expObj is long exp &&
  exp > int.MaxValue
)
{
  requireExpirationTime = false;
}

This workaround is very limited because the time validation may be different for different bearers (e.g., different users with different roles, different systems with different expiration times...) and some bearers need to be validated against time (with a short period of time, like 5 minutes) and others "don't" (15 years). I agree it may solve the issue for some users that has only one expiration time, but for others, it will just remove an important validation.

[mus65]

For anyone who needs a workaround: we worked around this by setting TokenValidationParameters.RequireExpirationTime to false if exp overflows.

if (
  DateTime.UtcNow.Year < 2038 &&
  jwtTokenParsed.Payload.TryGetValue("exp", out object expObj) &&
  expObj is long exp &&
  exp > int.MaxValue
)
{
  requireExpirationTime = false;
}

This workaround is very limited because the time validation may be different for different bearers (e.g., different users with different roles, different systems with different expiration times...) and some bearers need to be validated against time (with a short period of time, like 5 minutes) and others "don't" (15 years). I agree it may solve the issue for some users that has only one expiration time, but for others, it will just remove an important validation.

This actually works in our case because we are creating a new TokenValidationParameters instance for every single validation (we are not using using the ASP.NET Core extension methods where this may not be possible).

But yes, it's a bad workaround and I'm quite dissappointed that this still hasn't been fixed. 2038 is not that far off anymore and the longer the fix takes, the more legacy software will be broken by this.

[michaelhachen]

Same problem here. We really need a fix for this!

[jbcullis]

Yeah, this needs to be fixed....reported 8 years ago and the problem persists?
Seems to be a .net issue more than a AD issue as we are running into this on a .net7 web app.

[jennyf19]

This is fixed in IdentityModel 7.

[KalleOlaviNiemitalo]

IIUC, IdentityModel 7 doesn't support .NET Framework (#2123); how can I get the year 2038 fix for .NET Framework?