Wrong `verifyIssuedAt ` parameter

[sknr]

jwt/validator.go

Lines 115 to 120 in 6bcdd9d

	// Check issued-at if the option is enabled
	if v.verifyIat {
	if err = v.verifyIssuedAt(claims, now, false); err != nil {
	errs = append(errs, err)
	}
	}

When using the WithIssuedAt ParserOption, the internal verifyIssuedAt method must have the required parameter set to true instead of false otherwise the option only recognises if the token is issued in the future but not if the iat claim is missing.

[oxisto]

jwt/validator.go

Lines 115 to 120 in 6bcdd9d

	// Check issued-at if the option is enabled
	if v.verifyIat {
	if err = v.verifyIssuedAt(claims, now, false); err != nil {
	errs = append(errs, err)
	}
	}

When using the WithIssuedAt ParserOption, the internal verifyIssuedAt method must have the required parameter set to true instead of false otherwise the option only recognises if the token is issued in the future but not if the iat claim is missing.

This is probably bit of a philosophical question. The usage of this claim is completely optional according to the standard and so is its verification. So the question is what does the user expect here and this probably comes down to two-use cases:

1. Validate the issued-at date, if it exists
2. Require and the issued-at date and validate it

Currently, we chose to implement option 1, however I can see some benefit in option 2. What I would suggest is to have two flags: WithIssuedAt only does the validation and WithIssuedAtRequired (we have a similar flag for expired) controls whether it is required or not. We probably would also need to adjust the documentation to make it clearer.

Would you be open to implement a PR for this?

[mfridman]

We can't change this behavior in the current major version, this will be a non-backwards compatible change, especially because this claim is optional. I could see many users wanting the current behavior which is "validate only if present, ignore otherwise".

I'd be okay if we added WithIssuedAtRequired, similar to WithExpirationRequired. It's unfortunate we'll end up with 2 flavors, but this is a tradeoff for maintaining compatibility.