Upgrading the Endpoint Authentication Flow to use the Default Browser
As always, things change over time. If we look back 10 years ago, most customers didn’t enable authentication to access the Internet on their SWG. Instead, they would just use the local AD-joined credentials to enact policy. This ended up being pretty unreliable and SAML started to become a typical integration so that policy & analytics would be consistent… but then came AD synchronization, SCIM, and it just became a nightmare for admins.
So with dope.security, we chose to make this as easy as possible with two simple thoughts:
- You can only login using Microsoft 365 and Google
- You should only import Users & Groups from Microsoft 365 and Google
By doing so, there were some amazing consequences:
- No password pages built by our team, no password resets at all
- Instant trials with no email activation
- Instant SSO, because your Microsoft 365/Google OIDC presumably integrates with Azure AD, Okta, Ping, Onelogin, etc.
- One-click user/group import, because once you click authorize, you’re done and ready-to-go!
So, yes, it’s more difficult to support companies who don’t use Microsoft 365 or Google, but that has become a really, really small %.
Okay, but—tell me, how is this an upgrade?
Well, this whole experience is a huge time saver! I’ve seen with my own eyes that customers with thousands of employees have been able to sign up for a trial, enable authentication, import users, install an endpoint in under five minutes.
This is better than I (and our team) could have ever imagined!
Awesome, but—one more time, what’s new here?
Well, we initially started out with an “OIDC” pop-up that would initiate the authentication here:
However, this caused some challenges we saw in the field:
- Very rarely, this window would come up blank. This would naturally be pretty annoying to the employee and the only fix was to wait until it reloaded correctly. Not great, but luckily less than a handful of users were affected
- On Windows, this required the WebView2 library to be installed, which increases our package size, adds complexity, and overall, better to not have it at all
- FIDO U2F tokens, and other new-age authentication methods don’t work on Mac in WKWebKit webviews… so, customers had to use backup methods
- Re-authentication in general when you have an active session hampers user experience
The primary culprit is WebView—it creates this artificial “browser” that causes issues in the name of authentication. So, how can we fix this?
Use the Default Browser Instead!
There are a few methods like ASWebAuthenticationSession which allow you to invoke the user’s default browser rather than do the pop-up we were doing before. Unfortunately, the user can always tab away, close the window, or ignore it, but it’s up to us to subtly guide the user back to the happy path.
For example, we can block the Internet, and the browser shows up with a sign-in page instead. On Mac, we can even detect this window closing so that we can reopen it to prompt authentication.
By doing it using the default browser, you can use Passkeys, Fido U2F, Native SSO, and Password Managers—everything you’d typically use to log in. But most importantly, if you’re already authenticated in your default browser, just click “Sign in” and you’re done!
Wowza! That was easy!
That’s the idea with dope. We always want to make minor upgrades that everyone else ignores to make your life easier as a customer, as an admin, and as a user. We believe that this first-class experience is what makes dope better than anyone else out there.
So, what are you waiting for? Give it a try!
– kunala
