From memory: oAuth login flow
(browser based) was only supported on the windows client. For a Zero trust solution, having the only auth truly supported be a permanent JWT/Cert on the machine is doing device authentication, not user authentication, thus completely failing your primary objective.
UX was overall atrocious. Our users could not comprehend it at all. It was deemed that a custom client was required to be made.
The SDK first approach was an overall major plus point, allowing for a full customization to a specific use case.
Don't get me wrong we were overall impressed with the technology and the architecture choices. It's not a finished product, but something that does all the infra and you just need to apply the final veneer on top.
Ahh, I see, thanks for clarifying. That was correct, now any OIDC-compatible identity provider (Auth0, Okta, Azure/Microsoft Entra, Google, Keycloak, etc.) is supported on all the tunnelers to my knowledge.
Lots of work continues to go into the UX, but I would note that we focus most of the UI/UX work into NetFoundry, our commercial product.
The problems we had is users could not reliably tell when they were connected/disconnected, how to initiate the login flow, get network status (why is that service not working, but this other one is?), tell to which router they were connected, etc etc. I know these are big asks, and I suspect a lot of these troubleshooting and status info are probably available in the commercial offering.
That being said I think OpenZiti/NetFoundry is in a different class entirely and any lurkers here should consider it for their use. It's not really the same thing as NetBird or Tailscale.
Yeah, definitely more on the commercial side of the product.
And agreed, I like NetBird/Tailscale/Wireguard, but they are better VPNs, not identity-first, zero trust overlays as OpenZiti/NetFoundry is. That's why companies like Siemens have adopted it and many more will.
