jbreckmckye
commented
2 years ago It's pretty late in the evening here, way past midnight. This is a very dense report which covers quite a few things.
Let me first clarify what the actual problem is
- You want to use Auth0 with Google as an SSO provider
- You want to sign in on Electron (which is where this library comes in)
- This library uses an Electron browser window, which Google doesn't like as it doesn't trust embedded windows
This is an interesting one. I can see a few benefits to moving users to their default browser:
- They can see and verify the URL and certificates
- They can use their password managers or existing credentials
On the other hand, if we don't (e.g. by using a user agent workaround), we are in this situation:
- The token exchange itself should still be fine, it's more Google's trust of us that's the issue
- Whilst a casual user of the library won't have access to the browser window, it's very feasible to write a malicious electron app that attempts to spy on the challenge page. So Google will want to stop any workarounds eventually
- There's a social argument that it's better to train users to only do auth / 2FA through their browsers, always checking hosts, always checking certificates
The problem with changing the implementation is this:
For this to work, you need to host a static page that Auth0 redirects to after login. This page needs to have user instructions and JavaScript which returns the token to the app. There are few different ways to do this.
If I understand the ask correctly, that significantly increases friction for anyone implementing this flow. It also means anyone wanting to build an authenticated desktop app presumably has to deploy a web server as well to support this.
Now, the way this library works is based on a set of 'operations' and 'adapters', with the latter being swappable modules providing IO. One of those IO duties is the challenge flow and another is the verifier flow.
So it may be possible to support both approaches, with one set of adapters doing the browser window / clipboard sniffing trick, a la Slack. And then, if necessary, either deprecating the embedded flow over time, or making it non-default.
timfish
AriVagelatos-KSO
Google regularly reject logins made in a
BrowserWindow. I have MFA enabled on my Google account and it just doesn't allow it: https://support.google.com/accounts/thread/22873505?hl=enThe recommended way to do this is to open the Auth0 login URL in the users default browser via
shell.openExternal(url). This also has the added bonus that users are almost certainly already logged in with any auth providers so no need to do login+MFA again.For this to work, you need to host a static page that Auth0 redirects to after login. This page needs to have user instructions and JavaScript which returns the token to the app. There are few different ways to do this.
Localhost Websocket
I noticed Discord and a few others doing this. Your app exposes a websocket on localhost and any website, even one in a secure context can send it the token via the websocket. I haven't looked too deeply into this because it's complicated and it feels like opening a websockets to every website has security implications that I don't fully understand...
Protocol Handler
You're Electron app can register
my-app://protocol and you can redirect to that URL and the browser will pass the full URL to your app.I've got an app that does this but it has a number of downsides:
Clipboard
Courtesy of Ani Betts: https://twitter.com/anaisbetts/status/1470879935552237574