I use JWT plugin.
I craft all my JWT tokens using 1 single Consumer named 'auth-server'
The end-user email is encoded in the JWT payload.
{
"sub": "1234567890",
"email": "[email protected]",
"iss": "ec9493fb1af244d5a80c9ce8fefa2c1f"
}
I want my upstream server to receive the end-user email as Header.
example:
X-JWT-Payload-Email: [email protected]
or
X-Email: [email protected]
or
...
imo this should be done in a dual-plugin approach:
see also; https://github.com/Mashape/kong/issues/550#issuecomment-267298980. Much of the application logic can be shared this way.
@pouledodue I have done a proof of concept here:
https://github.com/wshirey/kong-plugin-jwt-claims-headers
You also need to account for requests that already have those headers set. You may could remove them with a request transformer before the jwt-claims-header executes.
This comes with no support :)
@wshirey I will try it tomorrow
This feature would be very nice indeed. However, passing the payload, as mentioned, in a "X-JWT-Payload" header would be enough. This gives the opportunity to parse the JSON on API / Microservice level, in contrast to hardcoding headers based on what the payload contains.
agree with @jovanmaric, a base64 encoded payload in a custom http header might be enough? no need to populate one http header for every key in the payload
yes would be enough
Any update on that? Do you plan to integrate this feature in kong?
The work of @wshirey seem great but you can't directly use it with kong's docker image.
If anyone gets here, I've written a plugin that does exactly this https://github.com/vnwonah/kong-token-to-header-extractor
Most helpful comment
This feature would be very nice indeed. However, passing the payload, as mentioned, in a "X-JWT-Payload" header would be enough. This gives the opportunity to parse the JSON on API / Microservice level, in contrast to hardcoding headers based on what the payload contains.