How can we create a single API proxy for GET, POST, PUT and DELETE but only grant access to specific method(s) to Client Apps

Consider the below scenario

There is an API proxy called "Proxy-A" with which one can have access to all methods GET, POST, PUT and DELETE which is protected by OAuth2.0 Client Credentials grant types.

I would like to grant access to only GET method of this "Proxy-A" to a Client App called "App1" and grant access to GET & POST method to Client App called "App2" and grant access to GET, POST, PUT and DELETE method to Client App called "App3"

Please anyone suggest how this can be implemented in Apigee and best practice.

Thanks in advance.

Regards,

Meenakshi Sundar.

Solved Solved
1 3 508
1 ACCEPTED SOLUTION

first, some background: the OAuthV2-VerifyAccessToken policy includes a Scope element; when you configure the policy like this:

<OAuthV2 name="OAuth-v20-2">
  <Operation>VerifyAccessToken</Operation>
  <Scope>YOURSCOPEHERE</Scope>
</OAuthV2>

That succeeds when the token presented in the Authorization header has been issued with the specified Scope.

Therefore, one good way to do what you want is:

  • create your single API Proxy with the various flows, GET, PUT, POST, DELETE, on various resources (like /foo, /foo/bar, whatever)
  • Create N different API Products. Each product should have a set of Scopes. API Product #1 might have a single scope: READ. API Product #2 might have 2 scopes: READ, WRITE. I'm not sure if it makes sense to have a 3rd API Product with scopes: READ, WRITE, DELETE, but if you want to do it that way, feel free.
    Each of these API Products wraps the single API Proxy.
  • Client App #1 gets authorized for Product #1. Client App #2 gets authorized for Product #2. Client App #3 gets authorized for Product #3. And so on.
  • Within the conditional flows, include the appropriately configured VerifyAccessToken policy. For example:

    <Flows>
      <Flow name='f1'>
        <Condition>proxy.pathsuffix ~/ "/foo" and request.verb = "GET"</Condition>
        <Request>
          <Step>
            <Name>VerifyAccessToken-With-READ-Scope</Name>
          </Step>
        </Request>
         ...
      </Flow>
      <Flow name='f2'>
        <Condition>proxy.pathsuffix ~/ "/foo" and request.verb = "POST"</Condition>
        <Request>
          <Step>
            <Name>VerifyAccessToken-With-WRITE-Scope</Name>
          </Step>
        </Request>
         ...
      </Flow>
      ...
    </Flows>
    	

The key thing is: each client app will obtain its token in the same way, via the standard client_credentials grant_type in OAuth2. But because the client presents different credentials, and because each id/secret pair maps to a different API Product in Apigee... and those products have different scopes.... the a token presented by the client authorized for Product #1 will be rejected by a VerifyAccessToken policy that requires Scope WRITE.

I hope this is clear. let me know if not.

A really good, in-depth, careful overview of using Scopes in Apigee is available here.

View solution in original post

3 REPLIES 3

first, some background: the OAuthV2-VerifyAccessToken policy includes a Scope element; when you configure the policy like this:

<OAuthV2 name="OAuth-v20-2">
  <Operation>VerifyAccessToken</Operation>
  <Scope>YOURSCOPEHERE</Scope>
</OAuthV2>

That succeeds when the token presented in the Authorization header has been issued with the specified Scope.

Therefore, one good way to do what you want is:

  • create your single API Proxy with the various flows, GET, PUT, POST, DELETE, on various resources (like /foo, /foo/bar, whatever)
  • Create N different API Products. Each product should have a set of Scopes. API Product #1 might have a single scope: READ. API Product #2 might have 2 scopes: READ, WRITE. I'm not sure if it makes sense to have a 3rd API Product with scopes: READ, WRITE, DELETE, but if you want to do it that way, feel free.
    Each of these API Products wraps the single API Proxy.
  • Client App #1 gets authorized for Product #1. Client App #2 gets authorized for Product #2. Client App #3 gets authorized for Product #3. And so on.
  • Within the conditional flows, include the appropriately configured VerifyAccessToken policy. For example:

    <Flows>
      <Flow name='f1'>
        <Condition>proxy.pathsuffix ~/ "/foo" and request.verb = "GET"</Condition>
        <Request>
          <Step>
            <Name>VerifyAccessToken-With-READ-Scope</Name>
          </Step>
        </Request>
         ...
      </Flow>
      <Flow name='f2'>
        <Condition>proxy.pathsuffix ~/ "/foo" and request.verb = "POST"</Condition>
        <Request>
          <Step>
            <Name>VerifyAccessToken-With-WRITE-Scope</Name>
          </Step>
        </Request>
         ...
      </Flow>
      ...
    </Flows>
    	

The key thing is: each client app will obtain its token in the same way, via the standard client_credentials grant_type in OAuth2. But because the client presents different credentials, and because each id/secret pair maps to a different API Product in Apigee... and those products have different scopes.... the a token presented by the client authorized for Product #1 will be rejected by a VerifyAccessToken policy that requires Scope WRITE.

I hope this is clear. let me know if not.

A really good, in-depth, careful overview of using Scopes in Apigee is available here.

Hi @Dino-at-Google,

Thanks a lot for your guidance, it helps a lot.

Wish you advance Merry Christmas and Happy New Year 2020.

Regards,

Meenakshi Sundar.

You're welcome! Thank you for the kind wishes. I also wish you a Merry Christmas (if that's your thing) and a happy health new year in 2020.