If you have an exp field but have set required claims to not include this field, then validate_exp currently will try to parse the claim. If the claim for example is not parsable, say you used a string based timestamp instead of a numeric timestamp, it should reject the validation instead of silently allowing the token through. This for example, would allow a token with a ISO8601 timestamp that is expired to pass because it was unable to parse. This was quite some surprising behavior, even though technically the JWT is not spec compliant I would expect the validation to catch that. This seems like a potential attack vector that is not covered by the validation logic.
If you have an
expfield but have set required claims to not include this field, thenvalidate_expcurrently will try to parse the claim. If the claim for example is not parsable, say you used a string based timestamp instead of a numeric timestamp, it should reject the validation instead of silently allowing the token through. This for example, would allow a token with a ISO8601 timestamp that is expired to pass because it was unable to parse. This was quite some surprising behavior, even though technically the JWT is not spec compliant I would expect the validation to catch that. This seems like a potential attack vector that is not covered by the validation logic.