Validate the `options` passed in to `jwt.decode`

samwho commented 1 year ago

We recently discovered a bug in our code that wasn't caught by tests because where we do jwt.decode we were supplying an option called "required": [...] instead of "require": [...], and so our JWTs weren't being validated to contain the expected fields.

So the call looked like this:

payload = jwt.decode(
  token,
  key,
  algorithms=algorithms,
  audience=audience,
  options={
    "keys": [...],
    "options": {
      "required": [...], # this should be: "require": [...]
  },
)

pyjwt doesn't complain about this, it continues without doing any checking that fields are present. It would have prevented us some pain if pyjwt raises an error when it receives an option it doesn't recognise.

If the project is willing to integrate this behaviour, I'd be happy to submit a PR making this change. 🙂

github-actions[bot] commented 1 year ago

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days

samwho commented 1 year ago

Bump to remove the "stale" tag :)

AndriiDubonos commented 10 months ago

Similar happened to our project. IMO, this is must-have for the library that is related to the security.

I found this PR where kwargs are marked with deprecation and planned to be removed in version 3.0. But more than a year passed from the merge of this PR and version 3.0 is not released yet. Do we have an expected time period when 3.0 will be released?

Until than, at our project, we are forced to make a wrapper around the 'pyjwt.decode` and extensively test all options.

jpadilla / pyjwt

Validate the `options` passed in to `jwt.decode` #869