Cookie 或标头发送自己的 API 以防止 Google Cloud Identity Aware Proxy (IAP) 302？答案

【问题标题】：Cookie or header to send own API to prevent Google Cloud Identity Aware Proxy (IAP) 302?Cookie 或标头发送自己的 API 以防止 Google Cloud Identity Aware Proxy (IAP) 302？
【发布时间】：2017-05-12 16:24:18
【问题描述】：

我已经在开发环境中设置了 Cloud IAP（使用 Kubernetes 启动并使用 Let's Encrypt），一切正常。

此应用的设置非常基本：

1) 一个 API，在项目 A

中具有多个 REST 端点和一个持久数据存储

2) 一个 SPA 前端应用程序，在不同的项目中使用上述 APIB

在我的浏览器（尝试过 Chrome 和 Firefox）中，我可以通过 IAP 屏幕在两个应用程序中验证我的 Google 用户（通过在浏览器选项卡中转到每个域），但是一旦我尝试使用 SPA 和它尝试向API发出请求，我看到网络请求 302 重定向到 Google IAP 登录页面。

问题：是否需要代表用户通过 API 请求发送标头或 cookie，以便 IAP 允许直通？

注意我看到这两个 cookie 顺便说一句 GCP_IAAP_AUTH_TOKEN 和 GCP_IAAP_XSRF_NONCE。

【问题讨论】：

关于这个问题，从长远来看，我选择为我的 API 做一个 IP 白名单......但仍然想回到这个问题。我正在开发一个可以帮助解决此问题的库，并且会自动将标头添加到您的 API 请求中（使用的是本机提取，但可以扩展到其他库）。但我遇到的问题也是我对 Web Sockets 的使用，它不允许发送自定义标头。

标签： cookies google-cloud-platform google-kubernetes-engine gcp google-iap

【解决方案1】：

什么受 IAP、“API”或“SPA”保护？如果是 SPA，IAP 应该可以正常工作。如果是 API，您今天最好的选择是使用 https://cloud.google.com/iap/docs/authentication-howto 让 SPA 对 API 进行身份验证，也可以将其传递给 https://cloud.google.com/iap/docs/signed-headers-howto，以便 API 可以单独验证最终用户的凭据。

将 GCP_IAAP_AUTH_TOKEN 从 SPA 传递到 API 将不起作用，出于安全原因，我们在将请求传递给最终用户应用程序之前将其剥离（如果负载均衡器和应用程序之间的传输是 HTTP，只是为了让生活对攻击者来说有点困难。）

【讨论】：

在这种情况下，SPA 和 API 都受到 IAP 系统的保护。
知道了。在这种情况下，我建议让 SPA 使用 service-account auth 指令对 API 进行身份验证，并且在该调用中，SPA 应该包括它从 IAP 获得的 X-Authenticated-User-JWT。 SPA 可以验证 JWT 并将其用作最终用户向 SPA 发起请求的证据。这不是一个 strong 机制，因为这些令牌不能提供强大的防止重放或篡改的能力——即控制 SPA 的人仍然拥有很大的权力——但它至少给了你一些基本的最终用户凭据检查。这对你有用吗？
是的，这听起来很合理，让我试试看！