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

JWT API: Offer a "strict audience" mode? #894

Closed
woodruffw opened this issue Jun 7, 2023 · 8 comments · Fixed by #902
Closed

JWT API: Offer a "strict audience" mode? #894

woodruffw opened this issue Jun 7, 2023 · 8 comments · Fixed by #902

Comments

@woodruffw
Copy link
Contributor

Hello again!

I'm raising this as a potential feature request for the current jwt.decode API.

Current behavior

The current audience is an Optional[Union[str, Iterable[str]]]. If a single audience value is passed verify_aud=True is passed, then the underlying API does the following:

  1. If the JWT's aud is a str, create a working audience list of [aud]
  2. If the JWT's aud is a List[str], use it as the working audience list
  3. Check if the passed in audience is included in the audience list

This is the right behavior in some JWT applications, but not in all. In particular, some JWT users may prefer to have "strict" audience checking, where passing in a single str means that the aud claim must also be a single str that exactly matches.

Proposed behavior

I propose the addition of an "strict_aud" (or "exact_aud") option in the options kwarg that gets passed into jwt.decode. When present and set to True, this should change the behavior as stated above: rather than constructing an internal audience list, it should enforce that the aud claim is only a single str that exactly matches the provided audience.

See pypi/warehouse#13887 for some justification for this new behavior.

If you're interested in this, let me know and I'd be happy to implement it!

@di
Copy link

di commented Jul 10, 2023

Hi @jpadilla, any thoughts on this? Would be great to have this downstream.

@auvipy
Copy link
Collaborator

auvipy commented Jul 11, 2023

If you're interested in this, let me know and I'd be happy to implement it!

I am positive for this, but open to know others opinion too

@jpadilla
Copy link
Owner

@woodruffw yeah let's do it, what you're proposing sounds good. @di thanks for the bump.

@woodruffw
Copy link
Contributor Author

Great, thanks @jpadilla!

I'll have some time this week to make a PR for this.

@woodruffw
Copy link
Contributor Author

Opened #902 for this!

@woodruffw
Copy link
Contributor Author

Thanks a ton @jpadilla! Any chance of a release for this new API surface? Otherwise I'm happy to wait, just figured I'd ask 🙂

@jpadilla
Copy link
Owner

Shipped v2.8.0 🎉

@woodruffw
Copy link
Contributor Author

Thanks a ton!

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

Successfully merging a pull request may close this issue.

4 participants