Google Identity-Aware Proxy
cloud.google.com
cloud.google.com
It's really an amazing way to think about security for a company. If you deploy it universally across your company, VPNs become obsolete. This solves a popular attack vector where bad-actors just need to get onto a corporate network to do damage. If you can authenticate at every service your employees connect to, it closes down that vector.
Considering Google has teams designing custom PCBs and even ICs, there's a non-insignificant amount of Google devs who could easily circumvent this entire system.
Even someone with serious hardware-foo would only be able to maybe break the trusted hardware bit (by cloning one device id to another, or emulating a device). They couldn't get round the two factor authentication bit.
I'd say it's still a pretty watertight model.
Obviously, getting entirely to that model is a lot of work, mostly for services which don't use HTTPS (network shares, ftp, smtp, ssh, enterprise java apps, etc.)
And people argued he had no option to hide it.
As I mentioned there, too, it's trivial to break that security if you have the knowledge to design and reverse custom ICs, and you could just steal the laptop of someone else, clone their trusted hardware system, and ensure their laptop is back in place.
Then later use that account to download the data to be sent to Uber.
I mean, for many cases of corporate espionage this is easily doable — it's just fancy DRM, after all. Not by the average dev, but for people who design this hardware or similar hardware in the first place, definitely.
We use mutually-authenticated TLS (ie, the proxy presents a client cert to your backend) so that you know the entire request is valid, including the username header. IAP only signs the header, which could be replayed because it's not bound to the session (eg, a debug page exposes request headers). But it's probably easier to grab a library that can validate JWT than worry about your TLS termination layer (eg, in a rails app behind nginx terminating TLS & serving asssets)
That said, I just use Caddy to proxy all my home's internal services with basic auth. At work I use the same setup, except it authenticates against our LDAP server.
Though client certs is definitely safer all around, more involved to spread around to apps talking to each other though.
As with AWS IAM, it manages access to the infrastructure, like your machine instances.
But this new Google thing, as far as I understand, is about giving other (potentially non-technical) users access to your corporate resources using single identity.
Because the proxy is examining requests, it can authorize them, and provide data to the back-end about what user was authenticated. A VPN usually just gets you onto the network, and doesn't provide much if any data to the service being accessed about what user and application is connecting.
A VPN is generally invisible to both sides of the communication, so you can tack on extra security, but it's harder to have the applications actually rely on it for authn/authz guarantees. In practice this means you have to log in twice: Once to the VPN, and again to the application. There's some ways to make that invisible to the user, though.
You can then have different whitelists per service.
Also IAP doesn't require the use of a VPN client. All one needs is a web browser with an internet connection. Giving your workers freedom to access corp assets just about anywhere.
BeyondCorp/UberProxy is just a really complicated whitelist. That's it. Super simple.