Using API products for authorization

Hello Apigeeks,

I am planning to use API products to achieve operation level authorization. I am planning to use scopes to identify the operations within a product. For e.g. if i have a customerAPI with /customers, I will create a product with /customers/** and READ scope and another product with /customers/** and READ UPDATE DELETE scope. I am able to achieve the desired functionality this way, but i see a drawback that I could end up with plenty of products as the no of APIs and their versions increase. I will also have to think of a meaningful naming convention for the products.

Has anyone faced this situation before? Does it impact usability from dev portal perspective?

Is it very hard to maintain?

Please share your experience. It will be really helpful for me.

Thanks

Snehal

Solved Solved
0 2 260
1 ACCEPTED SOLUTION

Hi Snehal - it seems as if you are on the right path, where you would have a customers product and an authorization product, if you were attempting to segment those actions out.

But is your question how to allow different levels of authentication for products, that have different "scopes?" Based on your example, are you suggesting:

API Product 1 (Read only) that can be accessed by one group of users.

API Product 2 (Read/Update/Delete) that can be access by a second group of users.

In this scenario, consider controlling those scopes through OAuth and API keys. This allows you to have a single API Product (Customers) and the scope is then controlled by who authenticates.

Here is some information that may help: https://docs.apigee.com/api-platform/security/oauth/working-scopes

Chris

View solution in original post

2 REPLIES 2

Hi Snehal - it seems as if you are on the right path, where you would have a customers product and an authorization product, if you were attempting to segment those actions out.

But is your question how to allow different levels of authentication for products, that have different "scopes?" Based on your example, are you suggesting:

API Product 1 (Read only) that can be accessed by one group of users.

API Product 2 (Read/Update/Delete) that can be access by a second group of users.

In this scenario, consider controlling those scopes through OAuth and API keys. This allows you to have a single API Product (Customers) and the scope is then controlled by who authenticates.

Here is some information that may help: https://docs.apigee.com/api-platform/security/oauth/working-scopes

Chris

Thanks Chris, i think this will solve my problem