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

Support for custom claims #15

Open
onematchfox opened this issue Oct 17, 2019 · 0 comments
Open

Support for custom claims #15

onematchfox opened this issue Oct 17, 2019 · 0 comments

Comments

@onematchfox
Copy link

We currently make use of Kong to set a number of "trusted headers" on requests that are to proxied to upstreams. This works fine if we can guarantee that the upstream will only ever accept requests from Kong. However, in on boarding some legacy applications we can no longer guarantee this and hence, I started looking into this plugin. This solves 95% of the problem but the signed JWT token does not guarantee that the other header's haven't been tampered with, nor does it prevent someone from re-using the token with a different set of headers within the 1 minute time interval that it is valid for. Thus, I have been looking for a way in which I could set custom claims using this plugin - as these are covered by the token signature and thus far less prone to spoofing.

At first I approached this by setting a custom value on the ngx context which was then read by this plugin. However, I don't like the mixing of code dependencies between plugins. So, I then settled on adding new a schema option that allow the user to specify that this plugin should convert a configurable set of headers into custom claims on the JWT token with the option of clearing the header after adding it as a claim to the JWT payload. Will submit a PR with this implementation. Would love to hear your thoughts on this approach or if you can think of a better one.

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

No branches or pull requests

1 participant