Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upValidate audience when payload is a scalar and options is an array #183
Conversation
…nce is an array
cgeers
commented
Feb 1, 2017
|
In addition to elegantly fixing the problem as described, the implementation here also addresses a separate problem I'm having validating the audience claim. When both the JWT aud claim, and the aud options field are arrays, the current verification implementation in 1.5.6 requires that all aud options elements be present in the aud claim of the token, but this behavior doesn't make sense (at least in my use case). The changes proposed here appear to behave such that aud verification will pass when any of the aud options are present in the aud claim of the token. This is a much more sensible behavior. +1 for merger, LGTM |
|
Thank you very much for this contribution. This fixes a lot of issues for the project. |
steti commentedJan 4, 2017
I recently updated from gem version 1.5.1 to 1.5.6 in one of my applications and I found that this behavior has changed. In my application, the JWT issuer creates the JWT with a scalar (string)
audclaim. The JWT consumer verifies theaudclaim against an array of possible values. The consumer has multiple valid names and a valid JWT could target any of those names as anaud. This works fine in v1.5.1, but the audience validation fails in v1.5.6. I'm not sure if this change was intentional. Based on my reading of the RFC this particular case seems like an implementation detail.