OAUTH2 APP/Product Configuration necessary

asharma377
Participant V

We have a set of API Proxies (more than 100 approx) that are being accessed by Mobile/Web team. We are not having any product/app configuration at this point in our account. We want to build masking and security mechanism now. Though these API's may not go public. Is it necessary to create app/product configuration and package these API's as part of them as we go on to build OAUTH2 security. (though we don't have any specific product, quota, developer requirements) at this stage.

Thanks,

Aakash

Solved Solved
0 4 194
2 ACCEPTED SOLUTIONS

@Aakash Sharma ,

Absolutely, API Products are core of API Program. Think about API Product as a Business Product / A Package that you will try to give as a feature.

We don't differentiate between internal & external APIs. For the matter of the fact, It's just the string at the end of the day.

API Products not only gives you security but also provides visibility with the help of Apigee API Analytics that helps you understand who is consuming your APIs.

Even if you don't have specific product, quota, developer requirements for external, YOU must need same for internal too.

What if some internal developer tries to execute a performance test on your backend servers by mistake ? Can you afford your backend servers going down ? What if your CXO, CTO would like to understand who is consuming you APIs ? Do you have visibility.

It's very important to think the big picture of API Program instead of focussing on small set of requirements.

Again, API Products are core of the API Program. Start thinking about end to end API Lifecycle & Create API Products straight away.

Hope it helps. Keep us posted moving forward if any.

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

Anil Sagar

5997-screen-shot-2017-11-23-at-75916-pm.png Learn Apigee Concepts in 4 Minutes HandsOn

View solution in original post

Is it necessary to create app/product configuration and package these API's as part of them as we go on to build OAUTH2 security. (though we don't have any specific product, quota, developer requirements) at this stage.

Yes.

Anil's remarks on the philosophy and approach of "API as a product" is important. Aside from that strong recommendation, there are practical reasons that you need an API Product.

This is the way OAuth tokens work in Apigee Edge:

  • bundle an API proxy (or more than 1) into an API Product
  • register a developer
  • Create an App for that developer, which is authorized for the API Product

This gives us "client credentials". With client credentials (and depending on requirements, maybe also user credentials), the client app can then request an OAuthV2 token from Apigee Edge.

Then, when the client app possesses the token, it can present the token as a bearer token in the Authorization header with every API request. The API Proxy in Apigee Edge calls "OAuthV2/VerifyAccessToken" to verify that the token is valid for an API Product that contains the active API Proxy.

View solution in original post

4 REPLIES 4

@Aakash Sharma ,

Absolutely, API Products are core of API Program. Think about API Product as a Business Product / A Package that you will try to give as a feature.

We don't differentiate between internal & external APIs. For the matter of the fact, It's just the string at the end of the day.

API Products not only gives you security but also provides visibility with the help of Apigee API Analytics that helps you understand who is consuming your APIs.

Even if you don't have specific product, quota, developer requirements for external, YOU must need same for internal too.

What if some internal developer tries to execute a performance test on your backend servers by mistake ? Can you afford your backend servers going down ? What if your CXO, CTO would like to understand who is consuming you APIs ? Do you have visibility.

It's very important to think the big picture of API Program instead of focussing on small set of requirements.

Again, API Products are core of the API Program. Start thinking about end to end API Lifecycle & Create API Products straight away.

Hope it helps. Keep us posted moving forward if any.

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

Anil Sagar

5997-screen-shot-2017-11-23-at-75916-pm.png Learn Apigee Concepts in 4 Minutes HandsOn

thanks for the useful information.

Is it necessary to create app/product configuration and package these API's as part of them as we go on to build OAUTH2 security. (though we don't have any specific product, quota, developer requirements) at this stage.

Yes.

Anil's remarks on the philosophy and approach of "API as a product" is important. Aside from that strong recommendation, there are practical reasons that you need an API Product.

This is the way OAuth tokens work in Apigee Edge:

  • bundle an API proxy (or more than 1) into an API Product
  • register a developer
  • Create an App for that developer, which is authorized for the API Product

This gives us "client credentials". With client credentials (and depending on requirements, maybe also user credentials), the client app can then request an OAuthV2 token from Apigee Edge.

Then, when the client app possesses the token, it can present the token as a bearer token in the Authorization header with every API request. The API Proxy in Apigee Edge calls "OAuthV2/VerifyAccessToken" to verify that the token is valid for an API Product that contains the active API Proxy.

thanks Dino will follow the advice.