Additional headers
willstott101 opened this issue · 5 comments
Sometimes it's useful to include a key ID in the JWT's headers - especially when working with key rotation.
It seems there's no way to do this right now - perhaps there should be a second callable?
Since user is passed to convert_cookie() and then to create_jwt(), which calls the configured callable, I would be OK with modifing the call stack to pass request and response instead of user. Then the callable could have additional side-effects such as setting headers, and could still access request.user to look up fields for the JWT.
I am OK with breaking backwards compatibility.
To be clear I'm talking about the header of the JWT, not the response headers: willstott101@77f0b07
In my case actually having this in the settings makes the most sense - and seems like a reasonable assumption.
OK, I get it now. Could the callable handle this? Let's say it returns something other than a dictionary of fields. Like perhaps a namedtuple with fields and headers members (for now).
IOW, we can make the existing hook more powerful rather than add more hooks.
Ok having thought about this a bit further I'm actually not a fan of adding complexity to the existing hook. I think simplicity and clarity of purpose are critical to keeping security plugins safe to implement/use.
Re adding additional headers... I actually wonder if it'd be better to support kid natively and not worry about letting users add arbitrary headers at the moment. All of the headers I can find real world references for are to do with the cryptography in use which is something this library should be handling. This might not be the case forever or for everybody but I do think it's something that could be looked at again when something new comes up.
I don't have a clear proposal yet, but I do think there's something better we can do to aid in key rotation. And it'll have to involve callables (for decoding as well as encoding). Personally I'd like a key-related callable to be seperate to a claims-related callable.