zlacker

> * SSO integration on all internal apps.

> * An authenticating proxy

I'm having trouble understanding what the fundamental difference is between these. Is it just a matter of a single, centralized proxy at the perimeter of your service network versus in-service SSO? Is there a functional difference between being in the same process space versus a sidecar on the same host versus a service on another host?

Ultimately it boils down to trusting the authority, whether that's a function (code review), a shared library (BOM), an RPC (TLS), a sidecar (kernel), or a foreign service (mTLS). There are different strengths and weaknesses for each of these, but it's not clear to me that the options you would prefer are distinctly more or less secure -- maybe there is an argument for defense in depth, but I'm not certain that's what you're pitching.

>>xyzzy_+(OP)
Most SSO solutions don't verify device identity or state, so you're not ensuring that the connection is coming from a computer you trust running software you trust.

>>mjg59+If
I guess it's a matter of what the IdP attests. It's definitely possible for an IdP like Okta to include a ton of client details as part of the attestation payload. Stuff like GeoIP, client certificate fields, MDM status, etc.

>>xyzzy_+Rq
Right, but you have to individually set up all of your apps to work with it; the proxy can be mandatory for all apps by dint of network controls.