# Kong bypassing custom plugin - OIDC **URL:** \ **Category:** General\ **Created:** [December 3, 2019, 9:31pm UTC](https://discuss.konghq.com/t/kong-bypassing-custom-plugin-oidc/5061 "2019-12-03T21:31:23Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![rush2subbu](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/rush2subbu/32/1553_2.png) [@rush2subbu](https://discuss.konghq.com/u/rush2subbu)\ **Post date:** [December 3, 2019, 9:31pm UTC](https://discuss.konghq.com/t/kong-bypassing-custom-plugin-oidc/5061/1 "2019-12-03T21:31:24Z")
Hello Folks, I’m aware that another user who is using the Kong Ingress controller + Plugin/Kong-ingress objects got this to work by fixing env variable KONG\_PLUGINS I have Kong 1.4 running on my AKS cluster , the ingress to Kong proxy is via our Nginx-Controller (ingress object for kong-ingress-data-plane svc on port 8000) Steps Taken so far to enable OIDC Plugin 1. Login into the kong-control-plane pod and execute - luarocks install kong-oidc - export KONG\_PLUGINS=oidc - Update the kong\_defaults.lua file with the value plugins = bundled,oidc - kong prepare && kong reload 1. I can confirm that OIDC plugin is installed curl -i [http://localhost:8001](http://localhost:8001) HTTP/1.1 200 OK Date: Tue, 03 Dec 2019 21:25:33 GMT Content-Type: application/json; charset=utf-8 Connection: keep-alive Access-Control-Allow-Origin: \* Server: kong/1.4.0 Content-Length: 6497 X-Kong-Admin-Latency: 6 {“plugins”:{“enabled\_in\_cluster”:[“oidc”],“available\_on\_server”:{“correlation-id”:true,“pre-function”:true,“cors”:true,“ldap-auth”:true,“loggly”:true,“hmac-auth”:true,“zipkin”:true,“request-size-limiting”:true,“azure-functions”:true,“request-transformer”:true,“oauth2”:true,“response-transformer”:true,“ip-restriction”:true,“statsd”:true,“jwt”:true,“proxy-cache”:true,“basic-auth”:true,“key-auth”:true,“http-log”:true,“oidc”:true,…,… 1. Create the Service and Route curl -i -X POST –url [http://localhost:8001/services/](http://localhost:8001/services/) –data ‘name=inventory-service’ –data ‘url=https://inventory.pet.contoso.com/’ curl -i -X POST –url [http://localhost:8001/services/inventory-service/routes](http://localhost:8001/services/inventory-service/routes) –data ‘hosts[]=[inventory.pet.contoso.com](http://inventory.pet.contoso.com)’ –data ‘paths=/product-inventory-kafka-proxy/’ –data ‘strip\_path=false’ –data ‘preserve\_host=true’ –data ‘regex\_priority=1’ 4) Now enable the ODIC plugin for the inventory-service on the route POST /services/inventory-service/plugins HTTP/1.1 Host: localhost:8001 Content-Type: application/x-www-form-urlencoded User-Agent: PostmanRuntime/7.20.1 Accept: _/_ Cache-Control: no-cache Postman-Token: 6acf67b4-9bd3-4947-9c5d-92d9572ff11a,5867e0ee-0869-445e-bae5-15284b8e1988 Host: localhost:8001 Accept-Encoding: gzip, deflate Content-Length: 446 Connection: keep-alive cache-control: no-cache name=oidc&config.client\_id=kongapi&config.client\_secret=#####&config.discovery=https%3A%2F%[2Flogin.microsoftonline.com](http://2Flogin.microsoftonline.com)%2F4a5b7942-b0b1-4244-b601-19f8e6c33e48%2Fv2.0%2F.well-known%2Fopenid-configuration&config.introspection\_endpoint=https%3A%2F%[2Flogin.microsoftonline.com](http://2Flogin.microsoftonline.com)%2F4a5b7942-0a52-nn779-19f8e6c33e48%2Foauth2%2Ftoken&run\_on=all&route.id=341e2900-8e44-4457-9aa3-17a857f2c4db 1. But when i test the proxy to the route , don’t get a 401 unauthorised , i get a 200 basicaly bypassing the OIDC auth\_flow/token validation flow Any help or guidance on what i might have done wrong is much appreciated cheers, subbu ---
**Author:** ![hbagdi](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/hbagdi/32/562_2.png) [@hbagdi](https://discuss.konghq.com/u/hbagdi)\ **Post date:** [December 3, 2019, 9:55pm UTC](https://discuss.konghq.com/t/kong-bypassing-custom-plugin-oidc/5061/2 "2019-12-03T21:55:57Z")
You should be deploying Kong as the Ingress controller instead of using Nginx. Make sure that you’re getting 200 OK from the correct service. It might be that Kong or Nginx in front of Kong are actually routing the traffic to a service different form the one that you’re expecting. ---
**Author:** ![rush2subbu](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/rush2subbu/32/1553_2.png) [@rush2subbu](https://discuss.konghq.com/u/rush2subbu)\ **Post date:** [December 4, 2019, 1:59pm UTC](https://discuss.konghq.com/t/kong-bypassing-custom-plugin-oidc/5061/3 "2019-12-04T13:59:42Z")
Thanks for the reply on this @hbagdi , The reponse is coming back from the correct upstream service , and we executed the Curl test from within the kong-ingress-data-plane (proxy) pod . Having said that , i will deploy the kong ingress controller and see if that alter the behaviour in this case ---
**Author:** ![rush2subbu](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/rush2subbu/32/1553_2.png) [@rush2subbu](https://discuss.konghq.com/u/rush2subbu)\ **Post date:** [December 4, 2019, 8:23pm UTC](https://discuss.konghq.com/t/kong-bypassing-custom-plugin-oidc/5061/4 "2019-12-04T20:23:55Z")
I wanted to get some clarification on this message that we see in the ingress-data-plane pod logs , could you pls help clarify: 8:13 [debug] 32#0: \*23901 [lua] init.lua:251: [cluster\_events] new event (channel: ‘invalidations’) data: ‘plugins:oidc::33716597-7699-4715-a037-d3162bf91953::’ nbf: ‘none’ 2019/12/04 20:18:13 [debug] 32#0: \*23901 [lua] cache.lua:204: [DB cache] received invalidate event from cluster for key: ‘plugins:oidc::33716597-7699-4715-a037-d3162bf91953::’ 2019/12/04 20:18:13 [debug] 32#0: \*23901 [lua] cache.lua:289: invalidate\_local(): [DB cache] invalidating (local): ‘plugins:oidc::33716597-7699-4715-a037-d3162bf91953::’ ---
**Author:** ![hbagdi](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/hbagdi/32/562_2.png) [@hbagdi](https://discuss.konghq.com/u/hbagdi)\ **Post date:** [December 5, 2019, 6:46pm UTC](https://discuss.konghq.com/t/kong-bypassing-custom-plugin-oidc/5061/5 "2019-12-05T18:46:02Z")
Those are related to cache invalidation happening in a Kong cluster. The data-plane node is receiving the events and purging the local cache as needed.