"invalid_request" error on authorization code generation

[williamspaul-1]

Trying to implement OAuth auth code generation, and I'm getting the infamous "invalid_request" message. I can't see any obvious cause -- perhaps a second pair of eyes would be helpful?

The OAuth Policy:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<OAuthV2 async="false" continueOnError="false" enabled="true" name="generate-auth-code">
    <DisplayName>generate-auth-code</DisplayName>
    <ExpiresIn>36000</ExpiresIn>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>GenerateAuthorizationCode</Operation>
    <GenerateResponse enabled="false"/>
    <ResponseType>request.formparam.response_type</ResponseType>
    <ClientId>request.formparam.client_id</ClientId>
    <RedirectUri>request.formparam.redirect_uri</RedirectUri>
</OAuthV2>

The Request (it's in a POST body):

POST /authorizations/authcode HTTP/1.1
Host: myorg-dev.apigee.net
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
Postman-Token: 055899d0-86be-516f-1de7-690d83d99c63

client_id=<app-id>&response_type=code&state=foo

Note that I also tried with and without a variety of other parameters like "grant_type" "scope" "redirect_uri" etc to the same effect.

The Response

{
  "fault": {
    "faultstring": "invalid_request",
    "detail": {
      "errorcode": "invalid_request"
    }
  }
}

I did look at the trace, but the trace also has few details. Is there a way to get a better diagnostic?

[hadleena]

Hi @Paul Williams,

I tried with the code that you had shared and I seem to get proper response for the same.

I have just changed the value of "GenerateResponse" to true to see the actual response.

[williamspaul-1]

d'oh.

The open question is still: how can we get better diagnostics from this policy?

[DChiesa]

I don't know how you get better diagnostics. It's a challenge.

But check your redirect_uri. Is it valid and correct?

[williamspaul-1]

So, the issue with the "invalid_request" was solved by setting the GenerateResponse to true. Apparently, this is a requirement of the proxy, despite the fact that the flag is documented as optional.

The question was more about the "go fish" response without any obvious diagnostics in the trace logs.

[DChiesa]

yes it would be nice if there were a message in the Trace session, something to give you a clue about what went wrong.

Did you raise a ticket?