Solved: Consuming Apigee API using AppScript

Edsasto · 04-11-2022 03:21 PM

Hi, I want to consume my Apigee API Proxy from an AppScript application using the

UrlFetchApp class. I can't do this because I can't find a way to send my TLS certificate (required by my infrastructure design) Using this class. Is there an approach that I could use to achieve this? Thank You

dchiesa1

I am not an expert on Google AppScript but it appears that UrlFetchApp does not support mutual TLS directly. [ see this and this ]. Therefore you cannot authenticate your client with mutual TLS, if you are using UrlFetchApp.

You may want to "work around" the problem by relaxing the requirement to use 2-way TLS, and use some other form of client authentication here. For example,

implement application-level security, as opposed to transport-level security. The client app can use a private key to sign a JWT, which it can send in to a /token endpoint to receive a token (like RFC 7523). And then the client can use that token directly on the Apigee endpoint. Both of those requests might be 1-way TLS.
implement a 2nd layer proxy. The client calls into the proxy service, which authenticates the client, again, at the application layer. The proxy thing uses 2-way TLS into the Apigee-managed endpoint. You'd have to write the proxy thing yourself, In python or whatever, and then host it yourself, in App Engine or etc. In this approach, the client to the proxy via UrlFetchApp is 1-way TLS , and the proxy to the Apigee-managed endpoint is 2-way TLS. The Apigee endpoint wouldn't change.

View solution in original post

dchiesa1

I am not an expert on Google AppScript but it appears that UrlFetchApp does not support mutual TLS directly. [ see this and this ]. Therefore you cannot authenticate your client with mutual TLS, if you are using UrlFetchApp.

You may want to "work around" the problem by relaxing the requirement to use 2-way TLS, and use some other form of client authentication here. For example,

implement application-level security, as opposed to transport-level security. The client app can use a private key to sign a JWT, which it can send in to a /token endpoint to receive a token (like RFC 7523). And then the client can use that token directly on the Apigee endpoint. Both of those requests might be 1-way TLS.
implement a 2nd layer proxy. The client calls into the proxy service, which authenticates the client, again, at the application layer. The proxy thing uses 2-way TLS into the Apigee-managed endpoint. You'd have to write the proxy thing yourself, In python or whatever, and then host it yourself, in App Engine or etc. In this approach, the client to the proxy via UrlFetchApp is 1-way TLS , and the proxy to the Apigee-managed endpoint is 2-way TLS. The Apigee endpoint wouldn't change.

Edsasto

Thank you for your answer, we didn't want to make a proxy and ask for infrastructure resources just to add a certificate to our requests but it appears to be our only option. JWT approach was not approved by my team

dchiesa1

You could also use a pre-built proxy, that requires only configuration. For example I thnk Envoy Proxy can accept inbound connections over -way TLS and then create outbound connections (to an upstream) via 2-way TLS. [ link ]

Envoy may be lightweight enough to run as a local proxy, on the machine that runs AppsScript. Or you could use a shared Envoy in a managed instance group.