Cookie or header to send own API to prevent Google Cloud Identity Aware Proxy (IAP) 302?

Question

I have setup Cloud IAP on a development environment (spun up with Kubernetes and using Let's Encrypt) and everything is working fine.

The setup is pretty basic for this app:

1) An API that has a number of REST endpoints and a persistent data store, in project A

2) A SPA front end app that utilizes said API, in a different project B

In my browser (tried Chrome and Firefox), I can authenticate my Google user in both apps via the IAP screen (by going to each domain in a browser tab), but once I try to use the SPA and it attempts requests to the API, I see the network requests 302 redirect to the Google IAP sign-in page.

Question: Is there a header or cookie that needs to be sent over via the API requests on behalf of the user so that IAP allows pass-thru?

Note I see these two cookies btw GCP_IAAP_AUTH_TOKEN and GCP_IAAP_XSRF_NONCE.

Silence

Regarding this issue, in the long run I opted to do an IP whitelist for my API instead ... but still want to come back to this. I was working on a library that would help with this, and would automatically add the header to your API requests (was using native fetch but could extend to other libraries). But the problem I had was also my usage of Web Sockets, which doesn't allow custom headers to be sent over. – Silence

Answer 1

What's protected with IAP, "API" or "SPA"? If it's SPA, IAP should work as normal. If it's API, your best option today is to use https://cloud.google.com/iap/docs/authentication-howto to have SPA authenticate to API, and maybe also have it pass down https://cloud.google.com/iap/docs/signed-headers-howto so that API can separately verify the end-user's credentials.

Passing down GCP_IAAP_AUTH_TOKEN from SPA to API won't work, we strip that before passing the request to the end-user application for security reasons (in case the transport between the load balancer and the application is HTTP, just to make life a little harder for an attacker.)

Odellodella

In this case, both the SPA and API are protected with the IAP system. – Silence

Got it. In that case, I'd suggest having SPA authenticate to API using the service-account auth instructions, and also in that call SPA should include the X-Authenticated-User-JWT it got from IAP. SPA can validate that JWT and use it as proof that the end-user initiated the request to SPA. This isn't a strong mechanism, as those tokens don't provide strong prevention against replay or tampering -- i.e. someone with control of SPA still has a lot of power -- but it at least gives you some rudimentary end-user credential checking. Does that work for you? – Odellodella

Yes that sounds reasonable, let me try it out! – Silence