You better not make an Electron app to “wrap” a website
TL;DR: Why investing in Electron apps might be a waste of time.
Imagine you work on a great web app, and one day, your PM walks to you and says: “Hey Joe, let’s make an Electron app that displays the main web app? Like Slack does.” What’d you say?
“The Wrappers” — Electron apps wrapping web apps for no reason.
I hope this post can change someone’s opinion about building an Electron app and save them some valuable time 🙂
Electron is a temporary thing
Yeah, Electron is cool, and it changed the way people think of “native” apps today, but let’s take a look at Electron concept from a bit different point of view:
- We can consider Electron as an excellent temporary solution that gives web apps access to the file system and allows them to execute code on the underlying system.
- At the same time, we can consider Electron to be a successful experiment demonstrating that developers and users want to see more “native-like” apps.
However, modern browsers already support many advanced capabilities: Web Bluetooth, hardware keys, Web NFC. See the full list here.
For example, Native File System API spec is already in Draft, and if you have Chrome 80–83, you can test it here.
Another proof of this — a fresh proposal to enable custom network protocols for PWAs (SSH, RDP, rich WebRTC). And according to the comments, it’s a promising feature for some use cases.
Although such features are still hidden in specs and proposals, it’s a flag that the engineering community is waiting for advanced capabilities in web apps.
Auth providers won’t allow users to sign-in through this app
>This is not applying to apps without “social” sign-in.
Image an Electron app displaying a website’s login page with a nice shiny “Sign in with Google” button. Fortunately, some users won’t be able to sign in through this Electron app.
For example, Google Auth detects when a user tries to sign in from an outdated browser (e.g., outdated Electron version) and rejects issuing a new session. The same goes for requests sent with custom UserAgent header.
For some reason, It doesn’t break auth for all users. But Google’s motivation is correct here because OAuth authorization server must identify unknown clients and rejects creating a new session.
Authorization servers should enforce this by attempting to detect whether the authorization URL was launched inside an embedded web view and reject the request if so. The particular techniques for detecting whether the page is being visited in an embedded web view vs the system browser will depend on the platform, but usually involve inspecting the user agent header. © OAuth.com
Auth providers, users and security teams discourage using such apps
Let’s get back to that nice Electron app and shiny “Sign in with Google” button that redirects users toaccounts.google.com right in the app’s webview.
There are stills two critical issues here:
- Users won’t be able to leverage cookie sharing between the system browser and Electron app
- (As a result) Users need to create a session in their SSO provider right in the webview, which is exclusively controlled by the Electron app.
Cookie sharing
Everything is already written in RFCs and guides about OAuth
…Many native apps are still embedding the OAuth interface in a web view inside the app. This approach has multiple problems, including that the client app can potentially eavesdrop on the user entering their credentials when signing in, or even present a false authorization page. (keep in mind, Electron doesn’t have an address bar)
…the embedded web view doesn’t share cookies with the system’s native browser, so users have a worse experience because they need to enter their credentials each time as well.
No cookie sharing option == bad UX.
Breaking the idea behind SSO
Imagine, the user decided to sign in to the web app (through Electron app) using Google. In this case, they will be redirected right in the Electron app’s webview to a Google login page to obtain a new session.
The problem is that now the Electron app can manage the user’s SSO account! Google account, in this particular case.
Let’s imagine this user is an IT admin, and their Google account is an SSO provider for something like JAMF. Sounds scary, right?
Possible solution
Implement something like OAuth2 in the auth server + at the Electron app side. It sounds like a pretty big task because implementing OAuth2 for Native apps is a pain (PKCE ftw!).
By the way, Slack doesn’t have CSRF protection for desktop app’s sign in flow :)
Electron = new security backlog
Electron + OAuth support on backend + OAuth support on web/native app side = new app? No! This Electron app also must be secure. So the developers will need to:
- Follow the Electron docs on securing the app.
- Check these helpful guides from Doyensec: this and that
- Use electronegativity in CI to detect a newly introduced attack surface. It’s a pretty good security scanner for Electron apps. Spoiler: Global installation is broken now; don’t try
npm i -gfor this package. - A typical issue for Electron apps is navigation to untrusted origins that can be achieved through an open redirect or malicious redirect from SSO provider. Make sure it’s not possible.
- Improve Content-Security-Policy for the web app. Otherwise, any stored XSS combined with an old Electron version may result in RCE.
Supporting native apps might be hard
All web app users always have the latest version (unless there is some cache in place). At the same time, once you deploy a native app, you’ll need to track the number of users on a particular app version. Users with an outdated version of the app likely won’t be able to access the service after some breaking changes.
Do you really need Electron?
It might not be reasonable to invest lots of time in an Electron app:
- It’s an overhead for the dev team (both support and development)
- It brings additional complexity to your system
- There might not be a benefit in bringing web app UX to desktop
I hope some sunny day PWAs will have feature parity with Electron apps. This day we’ll no longer need Electron, as it would be easy to make anything right in the browser.
