Feature Request: Open SSO Auth in Browser

[kevingunn]

When signing in to a VPN server using SAML, it would be nice if Viscosity used the browser instead of WebView. Most of our users already have an active session with the Idp, so utilizing that session rather than creating a new one in WebView for Viscosity would be an improvement to the user experience.

At the very least, make it an option in Preferences for users to select if the wish.

Thanks.

[James]

Thanks for your constructive feedback kevingunn, much appreciated!

Cheers,
James

[arkraft]

Hi,

I would also be interested in this feature. We are currently switching the Auth method for our VPN to SSO and due to the web view I have to login again and 1Password is not working inside the webvivew, so I have to copy my password over to the web view. This way using OpenVPN Connect is just a lot faster as it is just a click if I am already authenticated in the browser.

Kind regards
Artur

[James]

Thanks Artur, your feedback and listing your use case is appreciated.

Cheers,
James

[codyv]

+1 on this Open SSO Auth in Browser request. Logging in twice to single sign on brings the sadness.

[lindsey]

I would also be interested in this feature. I nearly always already have an active SSO session for other items and having to do it separately just for Viscosity is a large annoyance.

[James]

Thanks for the feedback codyv and lindsey - it's much appreciated.

Cheers,
James

[jhoos]

We have another use-case for having Viscosity support spawning an external browser rather than its internal WebView: we are trying to implement 2FA through Okta for our VPN, and it is currently incompatible with Viscosity's web view because our Okta setup requires the use of Yubikeys or other hardware keys, which we can't currently configure to work with Viscosity's web view (but obviously work just fine with standalone Chrome instances). We're currently debating migrating back to the stock OpenVPN client solely because it has this capability and Viscosity does not.

[rkrasko]

+1 this. We currently use MFA + device compliant checks with the IDP. Viscosity + Webview is not passing through the DeviceID to the IDP so the IDP thinks the request is coming from a new device. It would be better if we could just use the default system browser (in my case Edge).

[rmkjr]

Another +1. Enabling a setting to allow Viscosity to use the default browser, specifically on MacOS in my case, would allow us to use Entra ID's conditional access policies for our SAML flow. Currently Entra cannot check things like device compliance as the app's auth web view is not conditional access capable. If it used the default browser this check would work correctly.