Parse time claims as Number and convert to Long.

[nelsongraca]

When integrating with Jetbrains Hub as an OpenID provider, found that it returns the time fields in the JWT as seconds since epoch and miliseconds in the decimal part.

Example:

"exp": 1712762861.532,
"iat": 1705105035.125,
"auth_time": 1704986861.532,

This was causing a org.jose4j.jwt.MalformedClaimException to be thrown as Double can't be cast to Long at first sight this seems a bug in the OpenID provider, but the spec is vague about the definition.

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.

There is no specific mention that the value has to be Long.

This PR aims to prevent such cases by getting the Claim as Number and then returning it as a Long

Further information can be found on the Zulip thread: https://quarkusio.zulipchat.com/#narrow/stream/187030-users/topic/The.20value.20of.20the.20'exp'.20claim.20is.20not.20the.20expected.20type

Tests not added yet as I'm unsure how I can write such test.

[gastaldi]

Follow-up to #758

[Skyllarr]

Tests not added yet as I'm unsure how I can write such test.

@nelsongraca You can take a look at the DefaultJWTCallerPrincipalTest class. You can try to write a test by adding a claim updated_at in the new format

[nelsongraca]

@nelsongraca You can take a look at the DefaultJWTCallerPrincipalTest class. You can try to write a test by adding a claim updated_at in the new format

I looked into it but seems like I'll have to write a full JWT JSON to parse, or did I miss anything?

[sberyozkin]

@nelsongraca You can copy and paste a test like this one: https://github.com/smallrye/smallrye-jwt/blob/main/testsuite/basic/src/test/java/io/smallrye/jwt/auth/principal/DefaultJWTParserTest.java#L39, and set the claim in the token which is generated (see for ex, https://github.com/smallrye/smallrye-jwt/pull/758/files#diff-54a6e9144bee33f11a541e8e1ce7978cc8c1ce3cd8ed8599b5fa89d02b44bd73) and assert it is available in the parsed token

[sberyozkin]

@nelsongraca Ignore my comment please, easier to copy one of the test resources, indeed

[nelsongraca]

@Skyllarr and @sberyozkin added test for some of the time claims, only question is regarding best practice/convention, should I use static time, or dynamically with current time, both ways are in the code (one of the commented out), LMK which should be used.

[sberyozkin]

@nelsongraca Thanks, this is probably not testing the fix the best way.

Rather than modifying this legacy test code, can you please copy DefaultJWTParserTest into say TimeClaimsTest, and then create a dedicated simple JSON with the issuer, upn and the time claims only and have a single test confirming that retrieving iat, exp as individual claims works (there is no dedicated getter for the auth time in the current JsonWebToken interface but you can cast it to long)

[nelsongraca]

@sberyozkin yep can do it.

[nelsongraca]

Still need to move it to a new class, can't load from JSON though TokenUtils.signClaims will ignore the time claims in the JSON file and either use provided ones in the signClaims method (there's an overloaded version with those).

This is the original reason I'm not using a JSON with the claims, if there's something I'm missing or I'm not clear enough let me know.

[sberyozkin]

@nelsongraca Token verification step can be skipped for the test, since it is about asserting the parser correctly handles the JSON containing such claims, the verification has already happened at this stage. TokenUtils is an MP JWT helper only, it is not great for the general testing support, JWT Build API we ship is much easier and covers all the variations. Though with George's @gastaldi fix such claim values are converted to long but JWT Build API can be used to load an existing JSON too before signing it...

[sberyozkin]

The test can be made simpler, but it covers the fix, thanks @nelsongraca

[nelsongraca]

is there a date set when a version with this fix will be released?