Apikey and OAuth support for same proxy endpoint

We released our first cut developer portal APIs with simpler apikey verify policy.http://developer.plantronics.com/

Now with some of our integrator requirements evolving, we would like to add oauth 2.0 client credentials support. But, we want those endpoints with same base path to support api key as well for backward compatibility of pre exisitng integrations. I understand the proxy config cannot support two proxies with both oauth and api key support since it cannot match the same base path for two different proxies. What would be a best practice to allow backward compatibilities with apikey? Add another version like /v2 to our target backend?

----------

---------------------------

Solved Solved
0 1 774
1 ACCEPTED SOLUTION

Hi Manoj,

if i understand your query correctly, you are planning to add OAuth2.0 to an existing proxy which already has API Key. Current proxy already have consumers using API Key and going forward any new consumer will use OAuth2.0 is that correct?

If so, it is possible to do with existing proxy by using "conditions" . I created a sample proxy based on following assumptions, For ex: I am assuming clients for APIKey will be sending api key in header with name "appKey" and clients with OAuth2.0 (as per process) will send "Bearer" token.

You can check for header names in condition, for ex: if "AppKey" is present then VerifyAPIKey policy will be triggered, if "Authorization" header with bearer token present then OAuth2.0 policy "VerifyAccessToekn" will be triggered.

This process will help you to maintain backward compatibility , however at some point you need to move clients that are using APIKey to OAuth2.0.

Hope this helps.

6338-screen-shot-2018-01-25-at-41814-pm.png

View solution in original post

1 REPLY 1

Hi Manoj,

if i understand your query correctly, you are planning to add OAuth2.0 to an existing proxy which already has API Key. Current proxy already have consumers using API Key and going forward any new consumer will use OAuth2.0 is that correct?

If so, it is possible to do with existing proxy by using "conditions" . I created a sample proxy based on following assumptions, For ex: I am assuming clients for APIKey will be sending api key in header with name "appKey" and clients with OAuth2.0 (as per process) will send "Bearer" token.

You can check for header names in condition, for ex: if "AppKey" is present then VerifyAPIKey policy will be triggered, if "Authorization" header with bearer token present then OAuth2.0 policy "VerifyAccessToekn" will be triggered.

This process will help you to maintain backward compatibility , however at some point you need to move clients that are using APIKey to OAuth2.0.

Hope this helps.

6338-screen-shot-2018-01-25-at-41814-pm.png