Expiration date in Milliseconds always passes date validation

[yunus durmus]

Hi,

I am using JWT tokens from WSO2 and it sends expiration dates in milliseconds. According to the logic in the validation code, expiration date is compared to current time in seconds and it always wins since the comparison is based on long numbers.

Can we add a conversion of timestamps from milliseconds to seconds? For instance, we may simply check whether the value is higher than 4102444800L (2100-1-1).

I can also create a pull request if you agree.

Check NumericDateValidator:

NumericDate evaluationTime = (staticEvaluationTime == null) ? NumericDate.now() : staticEvaluationTime;

        if (expirationTime != null)
        {
            // if (!evaluationTime.isBefore(expirationTime, allowedClockSkewSeconds))
            if ((evaluationTime.getValue() - allowedClockSkewSeconds) >= expirationTime.getValue())
            {
                return "The JWT is no longer valid - the evaluation time " + evaluationTime + " is on or after the Expiration Time (exp="+expirationTime+") claim value" + skewMessage();
            }

[Brian Campbell]

Hi Yunus,

This is a reasonable request on the surface, however, the underlying issue is really a defect in WSO2 in not conforming to the IETF standard.

JWT/RFC 7519 defines "exp" as a NumericDate. http://tools.ietf.org/html/rfc7519#section-4.1.4

4.1.4.  "exp" (Expiration Time) Claim

   The "exp" (expiration time) claim identifies the expiration time on
   or after which the JWT MUST NOT be accepted for processing.  The
   processing of the "exp" claim requires that the current date/time
   MUST be before the expiration date/time listed in the "exp" claim.
   Implementers MAY provide for some small leeway, usually no more than
   a few minutes, to account for clock skew.  Its value MUST be a number
   containing a NumericDate value.  Use of this claim is OPTIONAL.

And a NumericDate is represented in seconds. http://tools.ietf.org/html/rfc7519#section-2

   NumericDate
      A JSON numeric value representing the number of seconds from
      1970-01-01T00:00:00Z UTC until the specified UTC date/time,
      ignoring leap seconds.  This is equivalent to the IEEE Std 1003.1,
      2013 Edition [POSIX.1] definition "Seconds Since the Epoch", in
      which each day is accounted for by exactly 86400 seconds, other
      than that non-integer values can be represented.  See RFC 3339
      [RFC3339] for details regarding date/times in general and UTC in
      particular.

I endeavor to keep this library free of "special" behavior to work around defects or non-standard implementations.

As a workaround, you can create your own Validator implementation that treats "exp" as milliseconds or does the conversion you described above and use JwtConsumerBuilder's registerValidator(Validator validator) to plug it into the JwtConsumer validation process.

Using something like .setMaxFutureValidityInMinutes(1440) on the JwtConsumerBuilder can also help detect and prevent JWTs with an "exp" that's unacceptably far in the future.

[Brian Campbell]

not a defect

[Brian Campbell]

The WSO2 folks are aware of the issue, have a ticket for it, and say it will be fixed in the next release. https://twitter.com/prabath/status/729812154325458944

[yunus durmus]

Thanks Brian, I'll go for the your temporary solution till it WSO2 resolves it.