Securing Electron Applications with OpenID Connect and OAuth2

[andrea.chiarelli]

Hey @pantneha47,
Thank you for joining the Auth0 Community and reading the tutorial.
Unfortunately, the image you provided shows no details about the problem raised.
To help you solve your issue, it could be useful to take a look at the messages associated with the Failed Login and Failed Exchange log entries.
Please, can you provide those details?

[david-blox]

Hi Andrea

This is what happened in the logs when user try to login → logout → login again.

When user try to login again from the login screen right after he clicked logout.
I get a message from auth0 api /token route:

The logout function run this:

logout = async () => {
  const { service, account } = this.keytar;
  await createLogoutWindow(`https://${this.auth.domain}/v2/logout?client_id=${this.auth.clientID}`);
  await keytar.deletePassword(service, account);
  storeService.logout();
  this.tokens = {
    accessToken: null,
    profile: null,
    refreshToken: null
  };
  this.userProfile = null; };

The logout window code:
import electron from 'electron';

const { BrowserWindow } = electron.remote;

export function createLogoutWindow(logOutUrl) {
  const logoutWindow = new BrowserWindow({
    show: false,
  });

  logoutWindow.loadURL(logOutUrl);

  logoutWindow.on('ready-to-show', async () => {
    logoutWindow.close();
  });
}

As you can see in the auth0 logs, even when the user have a successful login the /token api route returns 401 unauthorized.

If the user is closing the app opening it again and then try to login the /token route return a 200 OK.

Thanks a lot for your help,
David

[andrea.chiarelli]

Hi @david-blox, at a first look I’m noticing nothing wrong in your code.

The 401 HTTP status code may lead me to think that the value of the client_id parameter is not correct, maybe due to any wrong assignment. I think of this as a remote possibility, but please, check if the value of the client_id parameter is correct when you get the 401 HTTP status code.

Also, is there any special reason you are specifying the client_id parameter in the logout URL?
Have you tried to not provide the client_id parameter?
Have you configured any Allowed Logout URLs in the Auth0 dashboard?
Please, check out this document to get more info about using the client_id parameter.

Let me know if any of these attempts resolve your issue.

[danielr]

Hi,

Today google blocks rendering the login page on un-trusted browsers.
How does auth0 solve this issue for electron?

Better protection against Man in the Middle phishing attacks

[Atul]

I have 2 electron applications running on my local machine,as per blog i have implemented auth0 in both apps and used same env-variables.json file in both applications.
On logout from my first application it deletes all tokens from my machine , when i open my second application it doesn’t get refresh token and it goes to create auth0 window.
But loadTokens method gets called automatically from webRequest.onBeforeRequest because url contains code query parameter(http://localhost/callback?code=pGgrRpkkMmSKls36). How can i delete all sessions on logout so my second application open auth0 window when there is no refresh token available.

[andrea.chiarelli]

Hi @danielr,
If you are experiencing issues with that Google decision, you should open the login page in the system browser with the shell.openExternal() method instead of using loadURL(), similarly to how it applied here.
However, in desktop applications, this implementation opens a few issues related to usability and integration with the operating system. For this reason, in general, for Electron we are not suggesting this approach.
If you want to learn more, check out the following links:

• Securing Electron Applications with OpenID Connect and OAuth 2.0 - #4 by Vittorio

• https://auth0.com/docs/videos/learn-identity-series/desktop-and-mobile-apps#wistia_dq3c4pz9lb?time=620

[andrea.chiarelli]

Hey @Atul, I have a few questions since your scenario is not so clear to me.

1. The two Electron applications running on your machine are two instances of the same application or two different applications?
2. When you access the second application, don’t you get the Auth0 login page?

Also, you said:

…when i open my second application it doesn’t get refresh token and it goes to create auth0 window.
But loadTokens method gets called automatically from webRequest.onBeforeRequest because url contains code query parameter

The loadTokens() method is called automatically from webRequest.onBeforeRequest() after authentication, so it is not clear to me if, in your second app, the login page is shown or not.

Please, can you expand these points a bit? Thank you

[customautosys]

Hi, this article is helpful and works. However, why is it not an official Quickstart in auth0?

Also, why is there no official electron module that we can just npm install? I’m sure loads of people are using auth0 with electron.

[konrad.sopala]

That’s a good question! I guess you can share it as a feature request by creating a topic in our Feedback category here:

Feedback - Auth0 Community

[abi]

Would you recommend using the auth0-spa SDK? I’m trying to understand why you would write from scratch instead of leveraging either the SPA SDK or the node SDK. (Unless neither SDK will work for this application)

[robertino.calcaterra]

Hi @abi! Thanks for your comment! Let us do some research about this and we’ll back to you

[juan.martinez]

Hi @abi,

There are multiple ways to solve authentication and authorization in an Electron app, the SDK offer tools that you can use to simplify some tasks, but because of the nature of Electron some steps will require some custom code.

For this tutorial, the author and myself opt for not using an SDK as we wanted to showcase a pure implementation of the APIs, going through all the required steps, focusing on process isolation and other Electron best practices.

The SPA SDK can be helpful to handle functions such as login, logout, and others, but you will still have to decide the best way to store the refresh tokens if you want to persist sessions across tabs and refreshes.

If you are working with frameworks, for example, React, then again, it may be worth to use the auth0-react sdk with a custom token storage solution.

Hope this clarifies your question.

[abi]

Hey @juan.martinez thank you for your response! I really appreciate it.

Our Electron app currently connects to several APIs (Vimeo, Google, AWS) and writes tokens to a JSON in the user’s pref folder so they can be reused across app sessions. I’d like to follow this implementation with our auth0 API, so the SPA SDK doesn’t seem like a good choice for that particular use, since it doesn’t seem like you can access refresh tokens directly.

I found the Electron/auth0 tutorial incredibly helpful - thank you so much!

[juan.martinez]

Hi Abi, with the SDK you could still have control over where you store the tokens. By default the SDK will store them in memory, but you can opt to use local storage, or have your own solution plugged to the SDK to set the location, e.g. by using the user’s pref folder.

Here is more information about cache location for the SDK:

Auth0 Single Page App SDK

And the library docs for overriding the cache storage implementations:

https://auth0.github.io/auth0-spa-js/interfaces/auth0clientoptions.html#cache

Also be aware of the security implications of storing tokens, here is a guide for best practices:

Token Best Practices

Hope that helps,
Thanks!

[Shaggy]

Hello.

I am using an Auth0 SPA application for React with the @auth0/auth0-react SDK. I want to wrap my app in Electron but also deploy it as a web app (therefore I cannot rely on using auth0 native application).

What I have tried doing is using file:///callback for redirect_uri (added it to the list of allowed login callbacks as well), which results in an The specified redirect_uri 'file:///callback' does not have a registered origin error.

What should I do in this situation?

[juan.martinez]

Hi @Shaggy, I’d need a bit more context in what you are using. I tried simulating your situation and I got it working by:

1. Setting the Auth0Provider redirectUri to “file://callback” when the app is accessed through Electron (not to disrupt the web flow)
2. Initiate the login process with the function “loginWithPopup” instead of “loginWithRedirect” in the case of an Electron app
3. Set the allow callback URLs and allowed logout URLs with the value “file://callback”, plus the web values you probably have set. In my case: “http://localhost:3000,file://callback”
4. Loaded the static React build files into the Electron webview.

Please let me know if you still have issues after following those steps.

Juan

[andersheivoll]

Hi,

I’ve been using this article to set up auth in an electron app. After working fine for over a year, it suddenly started bugging up. On roughly half of the requests to get tokens, axios will throw an “Unexpected end of file” error - other times it will work just fine. The implementation is pretty much the same as in the article, with the exception of using some prod URLs.
Any ideas how this can be solved?

Thanks!

[andrea.chiarelli]

Hi @andersheivoll,
Welcome to the Auth0 Community!

Unfortunately, it’s really hard figuring out what is happening without having the code and the running environment at disposal.
Have you checked this recent axios issue?