OAuth Failure : Invalid API call as no apiproduct match found

Google Cloud Apigee
1

oauth1-rev1-2016-02-05.zipoauth2-rev1-2016-02-05.ziptestproxy-rev1-2016-02-05.zipWe are facing one issue with OAUTH in one of our current project in Telstra. Could you please help understanding the behaviour?

Little urgent – appreciate your help !!!

Case 1 :

An API proxy (named oauth1) to generate OAUTH2 access token client credential based. Has only OAUTH2 filter.

Another proxy named testProxy which validates the access token and do something.

Now to publish testProxy, I have created a Product named testProduct1 with only testProxy (without outh1 proxy) and a developer app named app1 registered to that product. When I call the OUATH endpoint (oauth1 proxy endpoint) with the client id & secret of app1 to generate the access token, it generates access token. Expected – no issue.

Case 2:

An API proxy (named oauth2) to generate OAUTH2 access token client credential based. Has 2 filters – 1. GetOAuthV1Info filter 2. OAUTH2 filter. (This is how it is has implemented somewhere, Not sure why !!)

Another proxy named testProxy which validates the access token and do something.

Now to publish testProxy, I have created a Product named testProduct2 with only testProxy and a developer app named app2 registered to that product. When I call the OUATH endpoint (oauth2 proxy endpoint) with the client id & secret of app2 to generate the access token, GetOAuthV1Info filter fails saying “OAuth Failure : Invalid API call as no apiproduct match found”. Now if I add, oauth2 proxy to the product, it works and generates the access token. Why so?

In general, what’s the standard practice – shall the OAUTH Proxy be included as part of the product explicitly (As case 2)? My understanding is OUATH proxy should be a treated as a generic proxy and should not be part of Product configuration as Case 1.

All the 3 proxies attached.

2

Hi @ravi.intipalli

I think I have the explanation for you. The reason the second case fails is because the OAuthV1Info policy in the “oauth2” proxy is trying to validate your API key (the client_id). At this point, the “product logic” basically executes these steps:

  1. Enumerate the API products associated with the app that was used to make the API call.
  2. For each product, check to see if the API product is valid for the app and the API call being made
  3. The first product that matches is used to set variables on the request that may be used by subsequent policies
  4. If no products match, then the API call is rejected

As you can see, your case falls through to step 4. This is because you are calling the “oauth2” proxy, and it is not in the product. That’s why when you add the “oauth2” proxy to the product, it succeeds.

I’d suggest just removing the OAuthV1Info policy from oauth2 proxy entirely (as you’ve done in the oauth1 proxy) unless you have a reason to use it there. It’s not really necessary — if you pass in invalid client credentials, the OAuthV2 policy will fail anyway. If for some reason you want to do key validation you’ll have to add that oauth2 proxy to your product.

One more thing, when you need to do API key validation, it’s recommended that you use the VerifyAPIKey policy, not the OAuthV1Info with “AppKey”. Hope this helps.