why the exp and iat put in the header section of the jwt?

[ghost]

I read the latest offical doc
and font that exp and iat is usually put in the payload part instead of header section.
should I use this or remove it and pyjwt instead??

[untitaker]

That appears to be an oversight, yeah!

[davidism]

itsdangerous implements JWS (with some extra headers in the timed case), not JWT.

Looking at the JWS spec, the only reference I can find to the headers you mention is in the payload of one of the example, where the payload is unrelated to the example. JWS itself doesn't define a payload format so it can't define how to store those fields there.

You appear to be looking at the JWT spec in the "claims" section.

[untitaker]

Oops sorry, I didn't really see that either!

[reubano]

@davidism is there any disadvantage to implementing JWT in this case? If JWS doesn't say one way or the other, it seems like it would make the most sense to follow JWT. CR #19.

[untitaker]

I didn't see that part. I think we could just cut a new release with the change though that will invalidate all Flask sessions.

[reubano]

I think we could just cut a new release with the change though that will invalidate all Flask sessions.

Isn't that what semver is for?

[untitaker]

Yes of course

[davidism]

I don't understand why this was reopened. You're still looking at JWT, not JWS. Just because we added extra headers (which is allowed in the spec) that are similar to JWT claims, doesn't make this JWT. Changing the current implementation would force all payloads to be dicts. As I've said in other issues about JWT and JWE, I'm fine with adding more serializers, if someone wants to implement one.

[untitaker]

Yes but the pr linked by @reubano indicated that Armin intended to implement JWT

[davidism]

Yeah, I understand that, at the time I guess the specs were ambiguous so they ended up with JWS with the time extension. Again, adding a separate serializer seems fine to me, now that everything's settled, but that's not what this issue was about.

[davidism]

If we do want to implement more of the JW* specs, I'd like to see this split into a package, it's already pretty unwieldy as a single file.

[davidism]

The intention of that other issue always seems to have been JWS, based on the name. Armin seems to just be commenting on the fact that JWT has a spec for timing that JWS lacks. I agree with his other observation that this whole thing is a mess. 🙁

[untitaker]

Whatever it is, I think we should decide on supporting JWT to end this once and for all.

[ghost]

seems I misunderstood the code..
I don't know it's jws instead of jwt ..
and please support that although I can use pyjwt.
but an official support save more time.

[ptallada]

Hi,

Please, move exp and iat to payload, otherwise it is incompatible with JWT specs and (at least) angular-jwt
Also it affects flask-jwt (pallets-eco/flask-jwt#40)

Thanks!

[davidism]

Contributions are welcome, but as stated we're not breaking the JWT spec because we're following the JWS spec.

[davidism]

Closing this.

The current serializer implements JWS, not JWT. The JWS spec does not include expiration, but does allow extra keys in the header, and we use that. If you're having trouble parsing a token, make sure whatever library you're using is parsing JWS, not JWT.

I also difficult to justify the added maintenance burden to implement and support JWT, when there are other Python projects that implement it. If you'd like to use JWT with the API provided by ItsDangerous, there are enough customization points to plug your JWT library of choice into a new Serializer subclass.