Unexpected behaviour of Apigee OauthV2 Policy

[Renuka_atnoor]

Hi Team,

We are using the OauthV2 Policy for generating Access Token with client_credentials grant type, we are testing for one scenario which has an Authorization header as Base64Encoding of key & secret and in form-param key & secret and grant type we are passing. While testing we observed some discrepancies in policy when we pass both the Authorization header and form-param with valid values it is giving successful response with a token, but when we pass the un-decodable token in the Authorization header it gives a 401 error code and response content as {"ErrorCode":"invalid_client","Error":"ClientId is Invalid"} which is expected but it not going to FaultRules.

One more scenario we tested was when we passed "Sample_Value" in the Authorization header, the policy threw a 400 error code and it is going to fault rule.

So we want to know why in the first case when it is an error it is not going to FaultRules.
PS. We have defined FaultRules for all the errors.

Thanks,
Renuka

@kurtkanaskie  @dchiesa1  @dknezic  @shrenikkumar-s  @Peeyush_Singhai 

[dchiesa1 · Accepted solution]

Hi

Thanks for the clear explanation. I think I was able to reproduce the behavior you described, here. I issued requests like these:

# Good credentials
curl -i $apigee/oauth2-cc-faultrules/token \
  -u $CLIENT_ID:$CLIENT_SECRET -d grant_type=client_credentials

# Invalid credentials
curl -i $apigee/oauth2-cc-faultrules/token \
  -H "Authorization: Basic dooakjd" -d grant_type=client_credentials

In the first case, good credentials, I got the response I was expecting. In the second case, I got the error you described. For me it looked like this:

{"ErrorCode" : "invalid_client", "Error" :"Client identifier is required"}

In this latter case, there was no fault. The variable fault.name was not set, and FaultRules did not process.

There's an outstanding bug (internal reference b/67167849), which covers the case that Apigee is not switching to fault processing in all cases, when the OAuthV2 policy fails. I believe what you observed is covered under that bug. Right now there is no fix available; the team is working on it.

In the meantime, I have a workaround for you. In your OAuthV2 policy, use <GenerateResponse enabled='false'/>. The side effect of this is that the proxy will enter fault processing when the policy fails. Then you can use a normal FaultRule. Be aware, you must manually assign the response in the case of success.

I've attached a working example proxy. The flow for /token uses <GenerateResponse enabled='true'/>, and exhibits the behavior you described. The flow for /token2 uses <GenerateResponse enabled='false'/>, and allows you to use FaultRules. In the case of an invalid client, the fault.name is InvalidClientIdentifier, so you can use

    <FaultRule name='rule1'>
      <Step>
        <Name>AM-Invalid-Client</Name>
      </Step>
      <Condition>fault.name = "InvalidClientIdentifier"</Condition>
    </FaultRule>

Good luck!