Security between Apigee and the backend service

[mohdilyas]

I have a use case where I want an API proxy to connect with a backend service to get some data. At the proxy layer, I already have token-based authentication but I want to have some authentication between Apigee and backend service besides having an MTLS.

Could y'all please suggest different approaches that you have taken in your projects?

[#2 · Accepted solution]

You can use jwt signature validation at backend for the token sent by proxy.

Access control policy can be used so that the backend will accept request only from the Apigee server.

You can use any third party identity and access management which will help the backend to decide the authenticity of the request.

[#3 · Accepted solution]

You can use jwt signature validation at backend for the token sent by proxy.

Access control policy can be used so that the backend will accept request only from the Apigee server.

You can use any third party identity and access management which will help the backend to decide the authenticity of the request.

[dchiesa1 · Accepted solution]

Really, it's up to you.

Most larger organizations that I work with have some sort of standard in place, or a set of standards or conventions, that prescribe

1. the kind of transport-level security that must be used (mutual TLS, but also, which cipher suites? etc), and
2. the kind of application-level security that must be used.

For the latter, some organizations prescribe a good/better/best approach.

"Good" might be, Apigee sends an API key that has a limited lifetime, to the backend system. That system validates it using ... some database lookup. This is really just for application identification and visibility.

"Better" might be a short-lifetime OAuth token. Very commonly, people use a signed JWT. The information in the JWT embeds at least a "client id" which identifies Apigee as the client, and an expiry, and is signed with a key associated only to the particular client. Figuring out how to securely manage these keys is important for preserving the security of the system. The receiving system needs to verify the JWT signature and expiry. The upstream (receiving) system could also evaluate other claims in the JWT, for example scope or some other custom claim.

"Best" might also include application-level signatures on the request. Something built on HMAC usually. Like HttpSignature (example here), or the cascaded HMAC that you see in AWS v4 signatures.