You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
If you have an
exp
field but have set required claims to not include this field, thenvalidate_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.The text was updated successfully, but these errors were encountered: