JWT token authentication fails due on non-integer timestamp claims

[hhurz]

What happened?

Validation of timestamp claims (exp, iat, ...) fails if these claims do not contain integer values.
EMQX checks if they are integers, which is not sufficient. It should check if they are numeric instead.
There are, in fact, servers that return microseconds as a fraction of float values.

What did you expect to happen?

Tokens containing timestamps formatted like that

  "iat": 1661429197.403285,
  "exp": 1676937402.387841,

should be accepted

How can we reproduce it (as minimally and precisely as possible)?

Generate a Token on https://token.dev/ or https://jwt.io/ which both allow to generate those tokens. Example:

{
  "typ": "JWT",
  "alg": "RS256"
}

{
  "aud": "Something",
  "jti": "70671c9ce3dd3461fa1ef0727c9cb4094cc71ed235646fdf30e0fa98d31df4b7f31054630b4389d8",
  "iat": 1661429197.403285,
  "exp": 1676937402.387841,
  "sub": "Subject of interest",
  "scopes": [
    "test"
  ]
}

Anything else we need to know?

The RFC 7519 for JWT does not restrict those claims to integers:

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.

EMQX version

All versions since EMQX 4.3.15 including 4.4.7 and 5.0.6

OS version

Tested on Debian and Windows

Log files

No response