kong-upstream-jwt
kong-upstream-jwt copied to clipboard
Optum
A plugin for Kong which adds a signed JWT to HTTP Headers to backend requests
It is more important to sign the data that kong has derived, and therefore is the authoritative source for; than signing the untrusted data that was passed into the http...
Plugin Enabled: $ curl http://localhost:8001 -s | jq .plugins | grep kong-upstream-jwt "kong-upstream-jwt": true, "kong-upstream-jwt", Kong.yaml: plugins: - name: kong-upstream-jwt service: bds-loan-booking route: bds-loan-booking-route 
The `x5c` JWT header produced by this plugin is currently invalid. This is because the header is set at https://github.com/Optum/kong-upstream-jwt/blob/0d558c89f345b8f906499285e56ea5bb39633ad6/src/access.lua#L83 using the local method at https://github.com/Optum/kong-upstream-jwt/blob/0d558c89f345b8f906499285e56ea5bb39633ad6/src/access.lua#L39 which also performs the...
This PR adds; - tests using Pongo (pass locally) - CI (which fails 😞 ) - a fix for an error message I suspect CI fails because of rights (accessing...
Ran into a little issue the other day. When updating the configuration of some containers, the location of our keys moved, but the configuration of this plugin was not updated....
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...
Add the ability to specify location (header field) of an existing JWT to copy a configurable list of claims from. Use case would be to proxy certain claims (`jti`, `aud`,...
Users of the plugin should have the option to exclude the x5c claim from the token. This becomes a security risk if the consumer of the token uses the embedded...
Make the `payloadhash` claim optional, so that the user has the ability to not set this claim when working with large request payloads.