OAuthV2 policy throwing error Invalid client identifier error if the policy is placed after a servicecalloutpolicy

fatemaali
Participant I

Hello,

OAuthV2 policy throwing error Invalid client identifier error if the policy is placed after a servicecalloutpolicy. If i place the OAuthV2 before the serviceCallOut policy the token is generated.

Please can you guide me how to resolve this.

Regards,

Fatema

0 3 1,461
3 REPLIES 3

What Operation have you configured in the OAuthV2 policy?

If it is a GenerateAccessToken, then the policy will look for client_id and client_secret in the Authorization header. if your servicecallout modifies the Authorization header, then the subsequent OAuthV2 policy will not find the client id where it expects. That is one scenario that would lead to the error you've seen.

Indeed i am configuring GenerateAccessToken operation and in servicecallout i am assigning new value to Authorization header. Is there a workaround for this can i store the Authorization header value before service callout and then again reassign this value before calling GenerateAccessToken. Or is there any other cleaner way to do this?

Oh yes, of course, I should have anticipated that question!

Yes, well... the way I would do it is to configure the ServiceCallout policy to use a distinct request. The context in Apigee carries things we call "context variables", and one of the always-defined variables is called "request". This variable allows you to read, and write, the various properties of the inbound request. So reading request.header.authorization allows you to read the authorization header. The OAuthV2/GenerateAccessToken policy implicitly reads that variable, as I Described above.

The ServiceCallout policy sends a request to a target URL that you specify. But which request does it send? You configure the request as part of the policy. You can send the request known as "request" or you can send a different request, one that you create and fill with independent data. For example

<ServiceCallout name='SC-1'>
  <Request variable='myrequestvariable'>
    <Set>
     <Headers>
       <Header name='content-type'>application/x-www-form-urlencoded</Header>
     </Headers>
     <FormParams>
       <FormParam name='username'>dino@apigee.com</FormParam>
       <FormParam name='password'>ILoveAPIs</FormParam>
     </FormParams>
     <Verb>POST</Verb>
    </Set>
  </Request>
  <Response>userAuthResponse</Response>
  <HTTPTargetConnection>
    <SSLInfo>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>true</IgnoreValidationErrors>
    </SSLInfo>
    <Properties>
      <Property name='success.codes'>2xx, 3xx, 4xx, 5xx</Property>
    </Properties>
    <URL>https://mylogin.com/auth</URL>
  </HTTPTargetConnection>
</ServiceCallout>
<br>

Executing that policy does not change the request variable. It sets all that request information into a new variable named 'myrequestvariable'.

Of course, you could copy the original request Authorization header and then restore it after the servicecallout, as you described, but that seems like the long way around to solve the problem.