OAuth Plugin Not Working - Kubernetes Ingress

I want to enable centralized authentication when deploying kong as a kubernetes ingress controller running with postgres database. Hence I deployed the plugin as decribed in this yaml file and added the plugin to the ingress component as shown in this yaml.

Even after applying the plugin I do not get an error if the Authorization header is not passed when making the api request through curl. I get a valid api response.

If I modify my application code to support OAuth2 authentication then it works (i.e. I get the 401 error) but that would defeat the purpose of having centralized authentication since each microservice would have to add support for OAuth2. I am hoping kong can do that centrally.

Could you please guide me on what could be missing?

Thanks.

Hi Shahamit,

I applied the plugin but it looks like it is missing a required field. If you take a look at the controller logs you will likely see something similar:

level=error msg="failed to update kong configuration: 2 errors occurred:\n\twhile processing event: {Create} plugin oauth2 for route 435e3c6f-a5b5-4a65-93e8-8273b541599b failed: HTTP status 400 (message: “2 schema violations (config.issuer: unknown field; config.provision_key: required field missing)”)

Additionally, you will notice the issuer field is not a valid parameter for the OAuth plugin, OAuth 2.0 Authentication plugin | Kong Docs.

Yes @joedas I realized that after troubleshooting it further. It seems the OAuth2 plugin makes kong acts an OAuth2 server whereas I am looking at it to act as an OAuth delegator. The OAuth introspection plugin would fit well for this use case (where Okta in this example acts as an OAuth2 server). Its available only in the enterprise edition though.

There is a third-party OIDC plugin that works for delegation without Enterprise. We don’t provide support for it and it hasn’t received updates for some time, but as far as we know it does work.

That doesn’t remove the need to add some application logic to handle OIDC, however–your applications do still need to send tokens, which will require code changes in many cases (browser applications using the authorization code flow are the exception, as they can usually automate everything via cookies). Your applications do still need to send tokens; the part the plugins automate for you is validating those tokens against the external IDP, retrieving ID tokens, and making authorization decisions based on claims.