Feature Request: Open SSO Auth in Browser

Suggestions/comments/criticisms are welcome here

dvlogic

Posts: 3
Joined: Fri Oct 20, 2023 8:27 am

Post by dvlogic » Thu Feb 29, 2024 4:43 pm
+1 on this request too. It would allow better integration with 1Password. Alternatively, a tight integration directly with 1Password would also work.

lix98755

Posts: 3
Joined: Tue Nov 05, 2024 7:37 am

Post by lix98755 » Tue Nov 05, 2024 7:44 am
Another +1 for this feature request., although this thread has been quiet for a while. Any updates on this?

We have a similar use case where we are trying to set up Okta OIDC integration with Viscosity and Okta MFA. Right now, Viscosity does not work with okta verify or security keys (like yubikeys, passkeys, etc). With WebView, Okta verify leads to an infinite loop and the security keys option just errors out. Additionally, if we can open sso auth in browser, users who have active Okta sessions will not be asked to log in again.

mheiland

Posts: 1
Joined: Fri Nov 22, 2024 10:18 pm

Post by mheiland » Fri Nov 22, 2024 10:21 pm
+1 since the current WebView solution breaks authentication with Passkeys or FIDO2 tokens. This works well with all major browsers and other VPN clients. It would be a shame if Viscosity would not support the latest and arguably greatest available authentication mechanisms.
Last edited by mheiland on Fri Nov 22, 2024 10:22 pm, edited 1 time in total.

James

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

Post by James » Wed May 21, 2025 11:03 pm
Hi All,

The latest macOS beta version of Viscosity (1.12b1 at the time of writing) now supports web authentication taking place in the default web browser. This should make it easier to authenticate in situations where an associated domain cannot be set, but it does mean that Viscosity cannot perform further validation of the site being loaded. Information on how to update to the latest beta version can be found at:
https://www.sparklabs.com/support/kb/ar ... -versions/

For enterprise machines, setting an "associated domain" via MDM is still the recommended approach. This enables the use of WebAuthn (aka FIDO2 or Passkeys) authentication without the need for an external browser, however the associated domain must match that of both the domain being used for the WebAuthn Relaying Party ID, as well as for the website making the request (it's possible to have multiple associated domains).

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Bluesky: https://bsky.app/profile/sparklabs.com
14 posts Page 2 of 2