I get nasty messages like these:
JWT … rejected due to invalid claims or other invalid content. Additional details: [[6] The JWT is not yet valid as the evaluation time NumericDate{1716031314 → 18 May 2024, 9:21:54 pm AEST} is before the Not Before (nbf=NumericDate{1716031315 → 18 May 2024, 9:21:55 pm AEST}) claim time.]
But the weirdest thing is that it’s intermittent. Sounds like a server time synchronization issue, right? But which servers? And why intermittent?
BTW, my remote server - it also serves as an Atlassian Connect app server - is using the same FIT validation code as in the official forge-remote-spring-boot
sample code. It works some of the time, so I can’t be doing anything too dumb, could I?
I found a solution:
var jwtConsumer = new JwtConsumerBuilder()
.setVerificationKeyResolver(getJwksVerificationResolver())
.setAllowedClockSkewInSeconds(10) // allow 10 seconds clock skew
.setExpectedAudience(appId)
.setExpectedIssuer("forge/invocation-token")
.build();
I added the .setAllowedClockSkewInSeconds(10)
. I figure that the Forge server and my Windows machine were not properly time-synchronized.
3 Likes
David thank you so much for posting and answering this. I am running into this same issue. I am using a windows machine. I have been hit with this time sync not just with forge (happened to me same exact way i.e. in jwt authentication) but also with other nodejs local development setups not involving forge.
Rest of my team who are on Macs do not hit this issue! It stalls me intermittently. So glad to find this workaround!
Here’s the equivalent when using the jose library:
const { payload } = await jose.jwtVerify(
forgeInvocationToken, JWKS,
{ audience: appId, issuer: ‘forge/invocation-token’, clockTolerance: ‘5s’ }
1 Like