3 ms·
I read a part of the article, but I'm confused. How is this different than making all our internal servers public and using okta or auth0 for sign in? I wouldn
by dangero 6y ago
I read a part of the article, but I'm confused. How is this different than making all our internal servers public and using okta or auth0 for sign in?
I wouldn't do that because any of those servers could have a security vulnerability that we're not aware of, so I feel like this must protect against that somehow, but I'm just not fully understanding what it does.
- m1keil 6y agoMain difference is that all of these websites are public behind one big proxy (ALB) and not public on their own. The security concerns are centralised in one place, not 10. That's not to say that the ALB can't have a bug or a misconfiguration that will render it wide open. But that's probably true for VPN as well.
- marcan_42 6y agoAnd the point of this is that, while application security is still important, it at least makes all those vulnerabilities post-auth, which is a huge improvement. The poor man's version of this is to put all your services behind an nginx reverse proxy with HTTP Basic auth (and TLS of course). For personal/small scale operations, this is a great way to almost completely eliminate your attack surface, if you have single-digit users and they can be trusted. Everyone running webapps personally should prefer this over, or in addition to, app-specific login systems.