Perhaps allow audience= and issuer= args to .encode() about pyjwt HOT 5 CLOSED

So, the big question here would be... how would you handle conflict? If a consumer passed in a payload to encode() that already had "aud" set but they also passed in a value for audience=

I think the best thing in that situation would be to throw an exception. It seems like any other option would result in a confusing API.

from pyjwt.

@wbolster hmm not sure I understand your proposal. Mind showing an example or use case?

from pyjwt.

Code to encode a token, e.g.

payload = {}
token = pyjwt.encode(d, key)

takes no audience= or issuer= args, while this does:

payload = pyjwt.decode(token, key, audience='foo', issuer='bar')

This means that application authors need to know internal details of the JWT spec if they want to generate tokens with audience or issuer claims embedded in them, since the only way to do so (currently) is to put aud and iss keys (with conforming values) into the payload dict. If applications put invalid data structures into those values, the token will be generated without error, but it will be non-compliant.

I argue that this is a discrepancy between encode/decode, since for decoding pyjwt takes care of the correct interpretation of the JWT spec to validate the audience and issuer claims, while for encoding application authors are on their own, since pyjwt doesn't help at all here.

Please let me know whether I've explained myself better this time. :)

from pyjwt.

@wbolster yeah definitely makes sense now

from pyjwt.

ok feel free to assign this issue to me. no guarantees about time frame but I'll see what I can do :-)

from pyjwt.