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
Could we set the default value of verify_iat to False and publish this breaking change as version 3.0?
Clients who understand the risks and want to engage in this extra-spec behavior should opt in by setting verify_iat to True, and the need to do this should be announced in the changelog for this new major version. (Or maybe there could be a global variable in pyjwt to control the verify_iat default?)
Timeline of this behavior
iat <= now validation was added in (I believe) the initial version of this library
The token is not yet valid (iat). #814 was deeply related to this issue, but in that particular user's case ended up being caused by a rounding error instead
I've filed an erratum report on the upstream JWT RFC here: https://www.rfc-editor.org/errata/eid7720. Discussion is ongoing, but the only controversy seems to be whether and/or how to publish the advice not do this, not whether or not this validation is appropriate. (Most seem to agree that this validation is not appropriate to perform.)
The discussion mailing list unfortunately appears to be private, but I've asked for either a public archive link (if one exists) and/or consent for me to share folks' responses if indeed the list is private; I'll update here if I receive either.
Justification
To copy/paste my previous comment on the closed issue:
This was litigated previously at #190. The JWT spec does NOT say to reject tokens with iat ("issued at") in the future, so this behavior goes beyond the spec and is inconsistent with manyotherJWT libraries.
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.
If token issuers want clients to specify that a token should not be accepted before a certain timestamp (which puts additional constraints upon clients by implying that clients' clocks should keep relatively in sync with a central clock source and/or need to check it with leeway) then the issuer is supposed to set nbf ("not before"):
The "nbf" (not before) claim identifies the time before which the JWT
MUST NOT be accepted for processing. The processing of the "nbf"
claim requires that the current date/time MUST be after or equal to
the not-before date/time listed in the "nbf" claim. Implementers MAY
provide for some small leeway, usually no more than a few minutes, to
account for clock skew. Its value MUST be a number containing a
NumericDate value. Use of this claim is OPTIONAL.
I am currently getting bit by this issue a lot in a large enterprise microservices environment (where token issuer, token user, and token-accepting server which validates offline using RSA are three different machines) where clock drift is coming into play. Myself and 10+ other people have now wasted multiple days of person-time trying to figure out why tokens were being rejected, talking about how best to address it, and managing the workloads & deliverables of the people investigating & talking about this.
Thoughts? Can we settle this once and for all?
The text was updated successfully, but these errors were encountered:
Opening a new issue since my previous rant about this was on a closed issue.
Request
Could we set the default value of
verify_iat
toFalse
and publish this breaking change as version 3.0?Clients who understand the risks and want to engage in this extra-spec behavior should opt in by setting
verify_iat
toTrue
, and the need to do this should be announced in the changelog for this new major version. (Or maybe there could be a global variable in pyjwt to control theverify_iat
default?)Timeline of this behavior
iat <= now
validation was added in (I believe) the initial version of this libraryiat <= now
validation was removed in 1.5.0 via Remove rejection of future 'iat' claims #252iat <= now
validation was re-added in 2.6.0 via Handling 'ImmatureSignatureError' for issued_at time #794 (current state)Other related issues
iat <= now
validation)Status of erratum report on official spec
I've filed an erratum report on the upstream JWT RFC here: https://www.rfc-editor.org/errata/eid7720. Discussion is ongoing, but the only controversy seems to be whether and/or how to publish the advice not do this, not whether or not this validation is appropriate. (Most seem to agree that this validation is not appropriate to perform.)
The discussion mailing list unfortunately appears to be private, but I've asked for either a public archive link (if one exists) and/or consent for me to share folks' responses if indeed the list is private; I'll update here if I receive either.
Justification
To copy/paste my previous comment on the closed issue:
Thoughts? Can we settle this once and for all?
The text was updated successfully, but these errors were encountered: