Back-end applications calling APIs via gateway

[#1]

Hi all,

We are in the process of architecting and introducing Apigee as our API management layer for both internal and external access to our APIs.

One of our key use cases is to have the APIs being consumed by internal server-side applications as part of their workflows (in which case it will not be triggered specifically by a particular end user).

The question is how would we secure our APIs for this use case? As it is a back-end application, it will be challenging to introduce oAuth type flows such as client credentials.

Would API keys be the recommendation for this use case?

[anilsr]

@Nischkalan Kanahia , Welcome to Apigee Community !

Great Question, Here is what i think about same.

Regarding, One of our key use cases is to have the APIs being consumed by internal server-side applications as part of their workflows (in which case it will not be triggered specifically by a particular end user). The question is how would we secure our APIs for this use case?

Since user is not involved & It's trusted environment, Client Credentials OAuth 2.0 grant type is the one recommended. But, I feel that it's fine to use Api Keys too in this use case.

Regarding, As it is a back-end application, it will be challenging to introduce oAuth type flows such as client credentials.

Agree with you, Changing backend code is challenging sometimes with workflows like oAuth2.0. Since you said, It's internal server side applications, You can go ahead and use API Keys instead of OAuth2.0 client credentials.

Whatever you do, use SSL / TLS. This is necessary to ensure that the authentication you perform really applies, in a not-alterable way, to whatever requests the internal application sends to your internal server.

PS: It's just my opinion, Appreciate if someone can contradict or have better answer.

[omidt]

Agreed. For system-to-system integrations without the user context and where both are in a trusted realm, I would recommend the OAuth 2.0 client credentials grant type. However, if it's not possible to configure or develop this on the backend, it's normally fine to fallback to a shared static API key.

I also recommend considering if two-way/mutual TLS is appropriate to your solution. This will give you protection at the transport layer, rather than (or as well as) the application layer.

[#4]

@Anil Sagar @Omid Tahouri thanks for the responses. Makes sense to me.

Just curious, these apis are likely to be consumed externally as well in which case we will need to provide the full oAuth authorisation code grant type. Is it possible in Apigee to have the same API proxy have both API Key verification and oAuth configured?

I'm thinking this would present a gap as an external application could just bypass the oAuth requirement and use an API Key - unless we can configure the allowed access control per application for the API in question?

i.e. when registering an internal application, configure to allow API Key Verification but for external application, configure to use oAuth.