Parsing/Validating a JWT token with invalid exp field fails on core 31.

[blowdart]

From dotnet/aspnetcore#25419

Bug description

JwtPayload.Exp throws if tokens contains a DateTIme instead of numeric value

Expected behavioud

It should return null

Details

The documentation of System.IdentityModel.Tokens.Jwt.JwtPayload.Exp states :

If the 'expiration' claim is not found OR could not be converted to <, null is returned.

However this is not the case. Exp property geter throws an exception if values is a Datetime. Here is a sample token

{
  "exp": "2020-09-08T21:18:18.5297739+02:00",
  "name": "tojename"
}

Please note that the payload is incorrect (exp should be a numeric type as per https://tools.ietf.org/html/rfc7519#section-4.1.4)

The JwtPayload.GetIntClaim() tires exception of type FormatException, InvalidCastException and OverflowException, but it does not handle InvalidCastException which is thrown by DateTime.IConvertible.ToDouble

My scenario is interop with some legacy service that created invalid token. This is not critical issue for me, I am just pointing out inconsistency in implementation/documentation.

The implementation ignores exp if it sets to "foo", but not if it set to a DateTime.
The documentation states that invalid values are ignored, but they are not for DaateTime.

[blowdart]

@matra774

[keegan-caruso]

Thanks @matra774 for reporting this.

@brentschmaltz do we want to get this into 6.7.3 or 6.7.3 +1?

[brentschmaltz]

@blowdart @keegan-caruso @matra774 it looks like our documentation is incorrect. The exp, iat, nbf claims should be NumericDate https://tools.ietf.org/html/rfc7519#section-4.1.4 . We should be throwing.

It would be prudent to ensure that JsonWebToken and JwtSecurityToken handle the same dates in the same way.

[matra774]

it looks like our documentation is incorrect.

Not just the docs, the implementation also. All incorrect data should be handled in the same way (now string are handled differently than DateTime when NumerDate is expected)

[brentschmaltz]

@matra774 yes i agree a "DateTime" such as "2020-09-08T21:18:18.5297739+02:00" is not NumericDate. However, if we modify this behavior and throw, we may break users.

[matra774]

@brentschmaltz I do not suggest to modify the behavior so that exp property getter throws. On a contrary. It currently throws, if a value is DateTime string - I suggest that it should NOT throw (as is the case if you use "foo" as the value for exp)

On a related note. The exp property currently returns int32 making it prone to year 2038 problem.

Currently token with high expiry dates behaves as if there is no exp field in the token. If you try to validate such token you will get exception IDX10225: Lifetime validation failed. The token is missing an Expiration Time.

Sample token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI1IiwibmJmIjoxNTk5NDExNDkxLCJleHAiOjIyMDQyMTE0OTEsImlhdCI6MTU5OTQxMTQ5MSwiaXNzIjoiaHR0cDovL215c2l0ZS5jb20iLCJhdWQiOiJodHRwOi8vbXlhdWRpZW5jZS5jb20ifQ.sXIRrKBgdnRfm2YLQnSn9fOcl3RGyXXpagkF9Z4jKno

[divyanshumehta]

@brentschmaltz I am getting a token exception message like this, is it related to this one. My token is valid and exp value is 1599280362

"IDX10223: Lifetime validation failed. The token is expired. ValidTo: 'System.DateTime', Current time: 'System.DateTime'."

[keegan-caruso]

@divyanshumehta

By default all parameters are censored. To show the parameters (potential PII) see:

https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/wiki/PII

[divyanshumehta]

ohh sorry I looked into it, i think since I am +3 hours from UTC that is why the token is always showing expired.

[brentschmaltz]

@matra774 i agree we have 2038 issue and will have to add a new API, so we don't break backcompat.

@keegan-caruso i see a couple of issues with out GetIntClaim to handle 'exp', 'iat', 'nbf'

1. Should we be allowing an array?
2. we should not be throwing if we can't be converting to int.

[jairofranchi]

@divyanshumehta

By default all parameters are censored. To show the parameters (potential PII) see:

https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/wiki/PII

@keegan-caruso This problem that @divyanshumehta reported, the only way to show the date would be setting this flag to true, right? Because if this exception is throw, in production environment the date will always be hidden, since doesn't make sense to show PII in production environments.

[brentschmaltz]

@jairofranchi assigning this to @sruke.

[jennyf19]

fixed in IdentityModel 7