Notifications
Clear all
Topic starter
19/08/2026 3:53 pm
TL;DR: OIDC in Electron apps centralises sign-in through browser-based federation, then returns users to the desktop app with stored session and refresh tokens, according to Descope. The pattern improves desktop user experience, but token storage, redirect handling, and session persistence still need identity governance controls rather than developer convenience.
NHIMG editorial — based on content published by Descope: Add Auth to an Electron App Using OIDC
Questions worth separating out
Q: How should security teams implement OIDC in Electron desktop apps?
A: Use an external browser for authentication, return users through a registered custom protocol, and keep token exchange, storage, and logout in a controlled service layer.
Q: Why do desktop apps make OIDC session governance harder?
A: Desktop apps often store session state locally, which extends the credential lifecycle beyond the browser and creates offboarding and revocation risk.
Q: What breaks when Electron apps rely on local token storage without strong controls?
A: Weak local token storage turns the desktop client into a recovery point for session theft, persistence, or stale access.
Practitioner guidance
- Validate redirect handling in the desktop trust boundary Test the custom protocol, callback parsing, and browser return path under normal and failure conditions so the app does not accept malformed or unexpected redirect inputs.
- Treat stored refresh tokens as governed credentials Classify on-device session and refresh tokens as sensitive identity material, and define storage, decryption, expiry, and revocation rules before release.
- Make logout an enforced invalidation event Ensure sign-out invalidates tokens across the full session chain, including any browser-held state and application-local persistence that could silently restore access.
What's in the full article
Descope's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step Electron configuration for OIDC redirect handling and browser handoff.
- Working auth-service.js patterns for authorization URL creation, token exchange, refresh, and profile lookup.
- Implementation details for SafeStorage and Electron-Settings token persistence across desktop sessions.
- Packaging and distribution guidance needed for deep linking and redirect behaviour to work correctly.
👉 Read Descope's guide to adding OIDC authentication in an Electron app →
Electron app authentication with OIDC: what IAM teams need to know?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
19/08/2026 4:30 pm
OIDC in desktop applications is still an identity governance problem, not just an application integration pattern. The browser handoff simplifies login, but it does not remove the need to govern session persistence, token storage, and logout semantics. Desktop apps often inherit the weakest parts of both worlds: browser federation on one side and local credential persistence on the other. Practitioners should treat the desktop client as part of the access surface, not as a harmless endpoint wrapper.
A few things that frame the scale:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to the AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: How do IAM teams evaluate whether cross-app OIDC reuse is acceptable?
A: They should assess whether shared session state creates unacceptable blast radius across applications, devices, or business units. The decision depends on whether the organisation can enforce consistent logout, claim freshness, and application-level session boundaries; if it cannot, cross-app reuse should be constrained or segmented.
👉 Read our full editorial: OIDC authentication in Electron apps reduces desktop login friction
