kong oauth2 route with GET method

I have been working on kong APIM recently and facing an issue related routes that are defined with GET method and using OAUTH2 plugin.
Routes that are defined with only GET method does not allow for requesting an access token.
Maybe I can better explain with an example that I was trying.

Steps To Reproduce

  1. Service definition:
    curl -i -X POST --url http://localhost:8001/services/ --data ‘name=ReadOnlyService’ --data ‘url=’

  2. Route added with only GET method:
    curl -i -X POST --url http://localhost:8001/services/ReadOnlyService/routes --data-urlencode ‘paths[]=/test123/cat’ --data ‘methods[]=GET’ --data ‘strip_path=true’

  3. OAUTH plugin added to “ReadOnlyService”
    curl -X POST -d “name=oauth2” -d “config.scopes=read” -d “config.mandatory_scope=true” -d “config.enable_password_grant=true”

  4. Adding new consumer
    curl -d “username=RO_Consumers”

  5. Creating an OAUTH2 application
    curl -d “name=Foo_1” -d “redirect_uri=http://httpbin.org” -d “client_id=RO_client” -d “client_secret=ro_client”

  6. Requesting access token:
    curl -d “client_id=RO_client” -d “client_secret=ro_client” -d “grant_type=password” -d “scope=read” -d “provision_key=rZzFaLPtQtxxXOadO7ZR3vGDXsQTagga” -d “authenticated_userid=ro_123” --insecure

Here response received is as => {“message”:“no route and no API found with those values”}
In the access.log it shows => - - [11/Jul/2018:15:54:53 +0530] “POST /test123/cat/oauth2/token HTTP/1.1” 404 69 “-” “curl/7.35.0”

Am I missing out something here?

Kong version: 0.13

If you find the answer to this question - I have a huge potential here to use kong and yet i still cant get this working

Interesting, makes sense because Proxy is locked down to GET only but OFC if you enable oauth2 on it you would hope logic could over-ride that default to allow POST get the token specifically on that /oauth2/token path (but it does not apparently in your testing).

In the mean time here is a working alternative, setup a separate global token URL and enable global on the oauth2 token generation like I described here:


Thanks Jeremy. Does the solution you mentioned is an standard way the OAUTH procedure are implemented ?

In my experience yes, most teams prefer to have a standard stand alone OAuth2 bearer token endpoint to transact against and not a changing ones to call on a per proxy uri basis.