Here “kong-test-user” is the client id of the party generating the API request and when I extract the information from the access token (jwt), I can see the azp claim properly in the patload, as “azp”: “kong-test-user”.
hide_credentials config does not get applied to the properly validated request. Backend server still get an authorization header with the generated access token.
Appreciate your inputs to properly configure this plugin to validate API requests either with client credentials or access tokens.
The verification of azp claim a bit problematic if you use different client than what you use for the plugin to acquire tokens. We may be able to loosen it, though I am not sure yet what is the best way to do it. Things like:
should you be able to specify your own clients in some additional parameter, such as config.allowed_azps
should you be able to specify claims for these standard verifications (which are causing pain as many idps don’t follow standards anyway), such as config.verify_claims_exclusions or otherway around.
@bungle, I didn’t find any specific configurations to disable any selected claims in the current releases. If it is available, that will be better in security perspective rather than disabling all the claim validations.
@hbagdi, I grabbed as much as information for the original post. If you need any explicit information, I can provide. Basically I am trying to understand the impact of disabling all the claim validations at oicd plugin, in a production systems.
Yes, I was just playing around with ideas. One additional idea is to have perhaps a bit more relaxed standard claims verification with bearer tokens. At the moment, yes, you can disable verify_claims. The signature is checked and expiry is checked even when that is disabled. I will think how to make it more flexible. Ideas are welcomed too.