Update pyjwt to 1.5.0

[pyup-bot]

There's a new version of PyJWT available.
You are currently using 1.4.2. I have updated it to 1.5.0

These links might come in handy: PyPI | Changelog | Repo

Changelog

1.5.0

1.4.21.4.2

---

Fixed

• A PEM-formatted key encoded as bytes could cause a TypeError to be raised 213

1.4.11.4.1

---

Fixed

• Newer versions of Pytest could not detect warnings properly 182
• Non-string 'kid' value now raises InvalidTokenError 174
• jwt.decode(None) now gracefully fails with InvalidTokenError 183

Got merge conflicts? Close this PR and delete the branch. I'll create a new PR for you.

Happy merging! 🤖

[EnTeQuAk]

Summoning @kumar303 and @diox for opinions on this. PyJWT removed validation for future iat values in jpadilla/pyjwt#252 with quite a bit of discussion in jpadilla/pyjwt#190 resulting in the decision that it's not defined in the JWT standard so it's applications responsibility to implement that check.

I do see points of both argument-sides but think validating iat for future-dates kinda makes sense. So I added that check and updated the tests a bit to also check for new pyjwt functionality validating that iat is an actual number.

r?

[diox]

I don't have a strong opinion regarding future iat values. @kumar303 ?

[kumar303]

If these tests still pass then maybe it's ok? We might do our own iat validation.

I haven't read the discussion but as I recall, protecting against iat manipulation does prevent some time-oriented attacks. I don't recall exactly what those attacks are but before removing iat validation (maybe this patch doesn't remove it) we should make sure it's ok to do so.

[kumar303]

oh, I see that you moved it over explicitly. I think that's a good thing to do, at least until we know can assess the usefulness of iat validation with security folks.

r+

[EnTeQuAk]

Perfect, thanks for the comments! I'll go ahead and merge this then so we simply keep our current functionality in tact but upgrade to the new version to stay up-to-date.