Token used before issued

[JorritSalverda]

Having switched from github.com/dgrijalva/jwt-go to github.com/golang-jwt/jwt/v4 I still get token used before issued errors due to clock skew, even though @dgrijalva said this check would be removed from v4, in line with jwt spec. See

jwt/claims.go

Lines 63 to 66 in 3f50a78

	if !c.VerifyIssuedAt(now, false) {
	vErr.Inner = fmt.Errorf("token used before issued")
	vErr.Errors |= ValidationErrorIssuedAt
	}

However I see that check is still executed at dgrijalva/jwt-go#314 (comment). Is this dependent on #16 getting resolved? Until that's resolved can the VerifyIssuedAt check just be dropped? Or any other suggested workarounds?

[oxisto]

Yes, this is somewhat dependent on #16. Meanwhile you can use jwt.TimeFunc to account for clock skew.

jwt/token.go

Lines 10 to 13 in 2ebb50f

	// TimeFunc provides the current time when parsing token to validate "exp" claim (expiration time).
	// You can override it to use another time value. This is useful for testing or if your
	// server uses a different time zone than your tokens.
	var TimeFunc = time.Now

[JorritSalverda]

Thanks, I'll test with

jwt.TimeFunc = func() time.Time {
		return time.Now().UTC().Add(time.Second * 20)
	}

to see if it gets rid of these errors.

[mfridman]

Hey @JorritSalverda did that solve your issue?

@oxisto Were we still interested in #16

[JorritSalverda]

Hi @mfridman for some reason it didn't help and i resorted to jumping through a lot of hoops to ignore this type of validation error, see https://github.com/estafette/estafette-ci-api/blob/main/pkg/clients/bitbucketapi/client.go#L277-L309

Looking at my logs the now value is actually larger than iat, so have to figure out how to get the actual value for now used during evaluation. I think though it's probably only off by a couple of milliseconds so not sure why overriding the TimeFunc didn't do it's job.

[mfridman]

Thanks for the insight. I think introducing (configurable) leeway could help with these sorts of issues.

Side note, every-time I see folks having to resort binary operators to determine the error it makes me cringe, because it's so prone to error.

[shogo82148]

Is the error "token used before issued" really needed?

RFC7519 says that:

https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4
The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing.

RFC7519 also says that:

https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.5
The "nbf" (not before) claim identifies the time before which the JWT MUST NOT be accepted for processing.

however, RFC7519 DOES NOT say that the "iat" (issued at) claim identifies the time before which the JWT MUST NOT be accepted for processing.
it just says that:

https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.6
The "iat" (issued at) claim identifies the time at which the JWT was issued. This claim can be used to determine the age of the JWT. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.

Some implementations of JWT have the maxAge option instead of the error "token used before issued".

https://github.com/auth0/node-jsonwebtoken/blob/74d5719bd03993fcf71e3b176621f133eb6138c0/verify.js#L199-L211

[oxisto]

Is the error "token used before issued" really needed?

RFC7519 says that:

https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4
The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing.

RFC7519 also says that:

https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.5
The "nbf" (not before) claim identifies the time before which the JWT MUST NOT be accepted for processing.

however, RFC7519 DOES NOT say that the "iat" (issued at) claim identifies the time before which the JWT MUST NOT be accepted for processing.
it just says that:

https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.6
The "iat" (issued at) claim identifies the time at which the JWT was issued. This claim can be used to determine the age of the JWT. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.

Some implementations of JWT have the maxAge option instead of the error "token used before issued".

https://github.com/auth0/node-jsonwebtoken/blob/74d5719bd03993fcf71e3b176621f133eb6138c0/verify.js#L199-L211

Yup, it is not really necessary to enforce it according to the specification. That is why in the long run it would be good to implement #16.

[oxisto]

@JorritSalverda Could you have a look at #139 to see if that mitigates your problem? Once we have that merged in, it will also pave way to a backwards-compatible way of configuration the validation. This was sort of a chicken-egg problem and we choose to merge in the egg first.

[rcmaples]

Is there a fix or workaround for this issue I can use before the various PRs are merged? I'm not sure I completely understand how my local system issuing the token and then validating the token in a subsequent request is subject to clock skew, but really hoping to find a workaround or solution here.
disregard. I'm still new here; updating to v4 resolved the issue.

[daniel-cohen]

@oxisto : For v4, Do you think we can also add an option to enable the issued at validation (should be disabled by default) to #139 ?

Something along the lines of:

func (c *RegisteredClaims) VerifyIssuedAt(cmp time.Time, req bool, opts ...validationOption) bool {
	validator := validator{}
	for _, o := range opts {
		o(&validator)
	}
	
	if validator.validateIAT {
		if c.IssuedAt == nil {
			return verifyIat(nil, cmp, req)
		}
		return verifyIat(&c.IssuedAt.Time, cmp, req)
	}
	
	return true
}

I don't think I'd want a leeway option for Issued at. I'd just want to turn it off.
But, we can combine the two as well:

func (c *RegisteredClaims) VerifyIssuedAt(cmp time.Time, req bool, opts ...validationOption) bool {
	validator := validator{}
	for _, o := range opts {
		o(&validator)
	}
	
	if validator.validateIAT {
		if c.IssuedAt == nil {
			return verifyIat(nil, cmp, req, validator.leeway)
		}
		return verifyIat(&c.IssuedAt.Time, cmp, req, validator.leeway)
	}
	
	return true
}

[oxisto]

@oxisto : For v4, Do you think we can also add an option to enable the issued at validation (should be disabled by default) to #139 ?

Something along the lines of:

func (c *RegisteredClaims) VerifyIssuedAt(cmp time.Time, req bool, opts ...validationOption) bool {
	validator := validator{}
	for _, o := range opts {
		o(&validator)
	}
	
	if validator.validateIAT {
		if c.IssuedAt == nil {
			return verifyIat(nil, cmp, req)
		}
		return verifyIat(&c.IssuedAt.Time, cmp, req)
	}
	
	return true
}

I don't think I'd want a leeway option for Issued at. I'd just want to turn it off. But, we can combine the two as well:

func (c *RegisteredClaims) VerifyIssuedAt(cmp time.Time, req bool, opts ...validationOption) bool {
	validator := validator{}
	for _, o := range opts {
		o(&validator)
	}
	
	if validator.validateIAT {
		if c.IssuedAt == nil {
			return verifyIat(nil, cmp, req, validator.leeway)
		}
		return verifyIat(&c.IssuedAt.Time, cmp, req, validator.leeway)
	}
	
	return true
}

We are still waiting for some minor last fixes in that PR. Once this PR is merged in, we would welcome any additional PRs on this validation topic.