Feature Request: Open SSO Auth in Browser

Suggestions/comments/criticisms are welcome here

kevingunn

Posts: 5
Joined: Fri Oct 15, 2021 5:24 am

Post by kevingunn » Thu Feb 02, 2023 6:17 am
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

User avatar
Posts: 2312
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Fri Feb 03, 2023 12:12 pm
Thanks for your constructive feedback kevingunn, much appreciated!

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

arkraft

Posts: 1
Joined: Fri Feb 17, 2023 8:20 am

Post by arkraft » Fri Feb 17, 2023 5:35 pm
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

User avatar
Posts: 2312
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Tue Feb 28, 2023 12:09 pm
Thanks Artur, your feedback and listing your use case is appreciated.

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

codyv

Posts: 1
Joined: Fri Aug 04, 2023 2:45 am

Post by codyv » Fri Aug 04, 2023 2:51 am
+1 on this Open SSO Auth in Browser request. Logging in twice to single sign on brings the sadness.

lindsey

Posts: 1
Joined: Fri Aug 04, 2023 2:50 am

Post by lindsey » Fri Aug 04, 2023 2:52 am
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

User avatar
Posts: 2312
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Mon Aug 07, 2023 4:00 am
Thanks for the feedback codyv and lindsey - it's much appreciated.

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

jhoos

Posts: 1
Joined: Thu Jan 18, 2024 4:35 am

Post by jhoos » Thu Jan 18, 2024 4:40 am
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.
Last edited by jhoos on Thu Jan 18, 2024 4:44 am, edited 1 time in total.

rkrasko

Posts: 1
Joined: Tue Feb 06, 2024 2:36 am

Post by rkrasko » Tue Feb 06, 2024 2:39 am
+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

Posts: 1
Joined: Wed Feb 07, 2024 6:40 am

Post by rmkjr » Wed Feb 07, 2024 6:45 am
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.
11 posts Page 1 of 2