Application level scopes with multiple products

[marcusdoron]

In the use case of having one proxy with a resource that has multiple verbs:

GET person

POST person

If I have two different applications:

app1 should only be able to use GET person

app2 should only be able to use POST person

Is it a best practice to use two products that both have the same proxy endpoint (Person),

But one has PERSON_READ scope, and the other has PERSON_WRITE scope,

So when using client credential, and oauth validation policy, it will have the right scope?

[dchiesa1]

In Apigee X you can create multiple products, each wrapping the same api proxy. Each product can have specific operations/ path pairs (GET /foo, POST /bar) that are allowed by apps authorized for those products.

You can also do this with scopes in any version of Apigee. To make it work you need to set the right scopes on the product and check the scope at Verify time.

[marcusdoron]

My question was, is it a good practice.

It means that I will create duplicate products, that are the same in every aspect, apart from the scope.

[dchiesa1]

---

@marcusdoron wrote:

 I will create duplicate products, that are the same in every aspect, apart from the scope.

---

I don't think it means that. Your app can be restricted on the set of scopes it can be granted. But it is possible to have different products with different scopes, if you'd like to manage things that way.  Is it a good practice? i guess it depends. Normally the set of scopes is "a handful", something like o(10).   Maybe 3 or 4 scopes on an API.  Having 3 or 4 different API products to support that, would be pretty clean.  

But sometimes the scopes are much more numerous. In healthcare contexts, for example, the regulations in the USA require very fine-grained permissions and scopes. And in that case, it would be practically impossible to have a distinct API product for each scope, or each combination of scopes. Even so, even in the H/C context it may be possible to have "some" API products that are mostly the same, but distinguished only by the set of scopes they support.  Eg, a handful of products curated to support 80% of the main use cases. And then you could handle the rest of the edge cases with scoped Apps. 

[PrakashJeya]

@marcusdoron  think you can set the scope at app level too. But this is allowed only via Management APIs and not in the UI as per the docs.  having said that App level scope at individual API operations can get messy and tricky to maintain. 

https://apidocs.apigee.com/docs/developer-apps/1/routes/organizations/%7Borg_name%7D/developers/%7Bd...

[PS: I realise this response is quite too late for you :)]