jwt
jwt copied to clipboard
golang-jwt
incorrect time
token, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
when I use JWT.Parse I get the error "Token used before issued",
after writing the entire token in the console I checked it manually several times and the iat variable is always returned with a time of 4 minutes into the future, e.g. for 10:00 the iat time is 10:04 which makes no sense.
the rest of the function works correctly
*I have the UTC +1 time zone on my computer but it shouldn't have any effect
src: https://pastebin.com/aU09PhkT
if it's useful to you, I've bypassed the bug by adding a function with a 5-minute time tolerance
const timeLeeway = 5 * time.Minute
if claims, ok := token.Claims.(jwt.MapClaims); ok {
now := time.Now().UTC() // set time to UTC
if iat, ok := claims["iat"].(float64); ok {
iatTime := time.Unix(int64(iat), 0).UTC()
if now.Before(iatTime.Add(-timeLeeway)) {
return nil, fmt.Errorf("token used before issue time (iat)")
}
}
if nbf, ok := claims["nbf"].(float64); ok {
nbfTime := time.Unix(int64(nbf), 0).UTC()
if now.Before(nbfTime.Add(-timeLeeway)) {
return nil, fmt.Errorf("token used before 'not before' (nbf) time")
}
}
if exp, ok := claims["exp"].(float64); ok {
expTime := time.Unix(int64(exp), 0).UTC()
if now.After(expTime.Add(timeLeeway)) {
return nil, fmt.Errorf("token is expired")
}
}
} else {
log.Println("Could not parse claims")
return nil, fmt.Errorf("could not parse claims")
}
There's a WithLeeway option that was added in case your application is tolerant of a bit of a leewway window.
I have recently started observing these errors in my logs, version 4.52, out of nowhere. I always use iat with time.Now() and nbf with now - 1 minute to avoid time sync issues. I wouldn't have thought the library itself started causing this. The 4 minute offset is very strange. Though I have not yet went into debugging my tokens, so it might not be my case. Just wanted to mention that I too am observing these in production.
BTW: @PAW122 now := time.Now().UTC() // set time to UTC is not necessary, the library handles this during marshalling, you can just use time.Now().
@ivanjaros When I was playing with this, I was manually counting the time from the token and the problem was in the token itself from what I remember.
I don't rule out the possibility that it's some problem with the token returned from the API itself. In that case, the library should take this into account.
*I recently used the library again and the problem persists. @mfridman as for the WithLeeway function if incorrect information is returned to the user by the API, i.e. the source of truth. In such a case, I think the library should handle the case when the token creation time is in the future, which is not possible.
Just small update - all my errors disappeared. I cannot say whether it was new deployment or server issue but my impression was that it was a server issue(maybe time drift?) that my provider resolved(again, just a guess).