Assuming an application is for internal use only (containing sensitive information), there are 3 ways to implement an authentication system.
- Self-implementation.
- Using third party auth providers like Google or Auth0.
- Using Identity-aware Proxy.
Between the 3 choices, self-implementation is too much of a hassle, so only (2) and (3) are most likely the way to go.
Using third party providers is the most well-known choice (e.g., Auth0), and it also offers ability to setup authorization mechanism (e.g., I can see my folder, but am I allowed to see admin panel?)
Identity-aware Proxy on the other hands is an authentication layer to prevent your request from reaching the server. It is used to replace VPN in cloud environment. In a sense, it also offers simple authorization as you can declare which group of users can reach the web server (not down to endpoint level though).
You can have both authentication mechanism implemented in your application, and an Identity-aware Proxy enabled.
With that said, for an internal web application (with sensitive information), is using only Identity-aware Proxy enough if there is no complex authorization involved? What are the downsides?
If you are using both at the same time, why? Also, if both Identity-aware Proxy and application login page use the same authentication provider (e.g., Google SSO), does it make the login page become redundant?
Top comments (4)
Hi, I'm a Director of Infrastructure for a B2B SaaS application & oversee my company's entire use of technology. My perspective won't speak to all use cases, but it does come with the insights of being the developer for auth, an administrator of systems, and a professional working with other businesses to establish sso.
SSO is the easiest solution to implement. It's highly accessible to companies of all sizes and requires very little configuration to implement. Over 50% of my customers federate their identities using SSO.
Identity proxies have valid use cases, but I view it as solving niche problems and requiring specialized skills that may not be as commonplace as integrating SAML 2.0.
Regrading the scenario about preventing traffic reaching the server - From an operations perspective, I only care about that if one of two situation is true:
Based on my experience, this would likely not be a concern for companies ranging in the 1-1,000 employee size, possibly upwards of 10,000. I could see companies with 100,000s of employees across their cloud networks having to take more preventative measures with traffic shaping.
Thanks for the detailed response, Joe!
I think you're on point about my concern, which is about the security of application. I agree SSO is relatively easy to implement (code-wise), but even with that amount of abstraction, there is a chance it is misconfigured.
For example, we have barebone Firebase SSO, but there are even more solutions out there that abstract away Firebase SSO to simplify the process like
Next-auth.Meanwhile, using Identity proxies is mostly just a toggle in your infrastructure, which is way less error prone. The proxy is handled by trusted providers with team of experts, so we can delegate this responsibility to them. For a simple application without much of authorization requirements, I think Identity-aware proxy only is enough.
What is your opinion on this?
Interesting you mentioned Firebase SSO, it's actually not a product I've integrated with, but I see why, it's more of something a developer adds to a project than a System Administrator adds to a company.
B2C sso doesn't have the same interoperability as B2B sso at the moment. SAML 2.0 has been around since 2005, so the spec has had 17 years to become adopted across B2B applications.
B2C SSO has more/less been an experiment since the early 2010s where they used OAuth in a manner that delivered the result, but OAuth wasn't specifically designed for the use case. This is why OIDC is now a up and coming standard that's interoperable in both a B2C and B2B setting, but it's still early in its adoption.
And while Infrastructure may look like a simple solution, it's still a niche skillset for configuring proxies. My org consists of 50 engineers, not including myself. Of those 50, 2 have past experience configuring proxies and are hesitant to invest in proxies without sufficient support. 5-8 are technically savvy enough to learn if presented with the task, but would be ill equipped to triage issues that may arise for all the different endpoints and views that an application can serve.
That's not to say that identity proxies are difficult, rather they're a specific tool for a specific job. My past projects have proven a little too complex to leverage proxies without breaking something that's not worth revising.
Much appreciate the insight!
It seems the proxies you mentioned are manually configured (i.e., physical), meanwhile, I'm more into fully-managed proxies, such as Google Cloud Identity-aware proxy or Cloudflare Access. I'm just not certain if they are readily viable solution. Certainly, the setup still requires infrastructure skills to set these up (like Google Cloud skills), not just a single-click solution. If you're already familiar with the procedure, then it becomes just a "toggle" to you.
I also think they are different tools for different jobs, it's just that I see an overlap which can be solved by using only Identity-aware proxies. That said, I'm still a newcomer to cloud technology, so these are just my humble opinion.
Here is an example if you're interested in. Thanks again for your great insight!