Reputation: 93
We are in the process of totally rewriting our main API Proxy config and we discovered an issue with our new configuration (or maybe our existing one) relating to how API keys are being validated. Our current API uses the policy GetOAuthV1Info
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<GetOAuthV1Info enabled="true" continueOnError="false" async="false" name="APIKey-Validate">
<DisplayName>APIKey-Validate</DisplayName>
<FaultRules/>
<Properties/>
<AppKey ref="request.queryparam.apikey"></AppKey>
</GetOAuthV1Info>
Our new configuration uses the policy VerifyAPIKey
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VerifyAPIKey async="false" continueOnError="false" enabled="true" name="Verify-Api-Key">
<DisplayName>Verify API Key</DisplayName>
<APIKey ref="request.queryparam.apikey"/>
</VerifyAPIKey>
On the surface both of these policies appear to work fine. However, after deploying the new config to our test environment some API keys were failing with a 401 Unauthorized error. Digging into those keys we discovered that they are assigned to a product that doesn't have access to the test environment. It appears that the GetOAuthV1Info step is not validating the environment..? The documentation for GetOAuthV1Info doesn't help as it doesn't talk about APIKeys at all (http://apigee.com/docs/api-services/content/authorize-requests-using-oauth-10a).
Fixing this particular issue is pretty straight forward in that we just need to allow those other products access to the test environment. However, this makes me wonder what the other differences are between these two policies? I'm very nervous now about deploying any changes to these API proxies because I don't know what else will break, or what other unforeseen issues will appear.
Is this a known limitation with the GetOAuthV1Info policy? Why does this even work at all? What are the other differences between these two policies that might bite me later?
Upvotes: 0
Views: 284
Reputation: 1208
The only difference that I'm aware of is that the variable names are assigned differently in the VerifyAPIKey Policy (it appends the policy type and name to the vairalbes like verifyapikey.verify_apikey-1.apiproduct.developer.quota.limit for example).
Both VerifyAPIKey and OAuth 1 does support restrictions by environment -- when I tested the GetOAuthV1 with an APIKey in an invalid environment and got this error:
OAuth Failure : Invalid API call as no apiproduct match found
Keep in mind that the convention for most projects seems to be either OAuth2 flows or the VerifyAPI so there is less information about the OAuth1 policies.
Upvotes: 0