Put the authoritative license decision on a server you control. The Electron app should ask that server, cache the answer for a defined period, and use the result to switch features on or off. Local checks in the renderer or main process are still useful for user experience and casual-tampering resistance, but they cannot prove that someone paid. This is an architectural conclusion drawn from the client/server model, not a rule stated in Electron’s documentation.
Why the installed app cannot be the authority
An Electron app runs on a machine the customer controls. Its JavaScript, bundled assets and any key shipped inside it can be inspected or altered by that person. If the full decision logic and every trusted secret live in the package, the check is a speed bump, not proof of payment. Electron’s security guidance explains that local code carries significant system power and that running untrusted code is dangerous, but it does not prescribe a licensing design. The conclusion here is general client/server reasoning.
As an Amazon Associate I earn from qualifying purchases.
Practical consequence: do not claim a local-only check is tamper-proof, and do not ship a private signing key or API credential in the app. A secret delivered to a customer-controlled client cannot stay secret in any strong sense.
What belongs in each layer
Renderer: presentation only
The renderer collects input (a license key, a sign-in) and displays states such as “licensed”, “expired” or “offline”. Treat anything it sends as potentially malformed or manipulated, and keep licensing secrets out of it.
#1 Best Overall
Main process: a narrow, validated gate
The main process should own the network request to your licensing service, or call a small, constrained licensing module. Expose it to the renderer through a deliberately small set of IPC handlers rather than broad Electron APIs. Electron is explicit about sender checks: “You should always validate incoming IPC messages sender property to ensure you aren’t performing actions or sending information to untrusted renderers.” Frames, including iframes in some scenarios, can send IPC messages, so validate the sender and the input before any privileged action. (Electron Security)
The same page warns: “A security issue exists whenever you receive code from an untrusted source (e.g. a remote server) and execute it locally.” Licensing responses should be data your app interprets, never code it executes.
Rank #2
Licensing service: the source of truth
For connected products, the service decides account status, subscription state, activation counts and revocation. It is the only place that can enforce those decisions for anything you serve remotely. The costs are real: availability requirements, operating expense, privacy obligations and support load. A recent DEV article illustrates the client-to-license-API pattern using a named hosted provider; that provider’s claims, pricing and security properties are unverified here, so treat it as an example of the pattern, not an endorsement.
Free tools Windows power users keep installed
One-click scans. No signup required.
Transport
Use HTTPS for every call to the service. Electron recommends secure protocols for resources not bundled with the app, and HTTPS gives integrity and eavesdropping protection in transit. (Electron Security)
Rank #3
Can an Electron app validate a license offline?
Yes, within limits. The usual approach is for the server to issue a signed entitlement artifact with a limited validity window. The app caches it and verifies the signature with an embedded public key. The app never needs the private signing key, because verification material can be public. This is a design recommendation; no source here verifies a specific implementation or a recommended validity period.
Offline behavior is a product policy, so decide and document it:
Rank #4
- Does the app start offline at all?
- How long is a cached entitlement honored before it must be refreshed?
- What happens when a check fails because of a network error versus an explicit “not entitled” answer?
- What happens on expiration or revocation: read-only mode, reduced features, or lockout?
- How are clock changes, device migration and reinstalls handled?
An offline client cannot receive instant revocation. Revocation takes effect at the next successful refresh or when the cached artifact expires, whichever comes first. No source establishes a universally correct grace period.
Choosing a policy
| Approach | Revocation speed | Outage tolerance | Privacy footprint | User friction |
|---|---|---|---|---|
| Online-only check | Fast | Low | Highest (frequent contact) | Highest when offline |
| Cached, signed entitlement with expiry | Bounded by validity window | High within the window | Moderate | Low to moderate |
| Perpetual local license | None after issue | Highest | Lowest | Lowest; weakest against sharing |
Also weigh support burden, service operating cost and resistance to casual tampering. No single policy fits every product; subscriptions that gate server-side features suit the first two, while one-time purchases of fully local tools often suit the third.
Code signing does not prove entitlement
Code signing helps certify who built the app and that the distributed package is trusted. It says nothing about whether a given account or installation has an active subscription. Keep the two concerns separate. See Electron’s code signing and distribution overview pages for the packaging side; neither is a licensing specification.
Quick Recap
Recommended pattern in short steps
- Authenticate the user or key against your service over HTTPS from the main process.
- Have the service return a signed, time-limited entitlement.
- Verify the signature locally with a public key and cache the result.
- Expose only a small IPC surface that reports state to the renderer, validating the sender on each handler.
- Gate features in the main process using the verified entitlement, and gate anything server-hosted on the server itself.
- Refresh on a schedule and on startup, and apply your documented expiry and offline rules.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
