Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'iat' handling doesn't conform to spec? #84

Closed
MPiccinato opened this issue Feb 9, 2016 · 2 comments
Closed

'iat' handling doesn't conform to spec? #84

MPiccinato opened this issue Feb 9, 2016 · 2 comments

Comments

@MPiccinato
Copy link

Hello, first of all, great library and thanks for putting it together.

My question pertains to the RFC-7519 spec for the 'iat' claim and how it is handled in this lib.

4.1.6. "iat" (Issued At) Claim

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.

Since the spec says this claim is optional and doesn't specify the validity of an 'iat' claim, other than being an NumericDate value, shouldn't the library not enforce validity by default?

I see you can specify a 'leeway' time to account for clock variations and the 'iat' will be checked with this value but doesn't this break the specification? Wouldn't it be better to allow the consumer of the library to specify if the 'iat' claim should be checked outside of the NumericDate value requirement?

@AndrolGenhald
Copy link

Just ran into this as well due to clock skew (I think ntp is blocked by firewall).

AndrolGenhald added a commit to AndrolGenhald/php-jwt that referenced this issue Jun 1, 2017
@bshaffer
Copy link
Collaborator

This is correct - we mistakenly validated the iat instead of the nbf field. We'll have to remove this check in a future version.

Closing as a duplicate of #475

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants