Authorization with electron.net

[domingoladron]

I've been trying this for a week and still little success.

Auth for a blazor server app, np. Auth for an electron native app has a few more working parts but still doable. Put them together...not so easy.

Has anyone successfully bridged the authentication and authorization between the native app aspects in js /ts and the web aspects in .net core?

I want users to login to my native app via say Auth0, then with the IUserPrincipal, interact with the blazor app using said creds. I can't imagine I'm the only poor sod chasing this dream.

I could also just have them log into the web app using normal web flows inside my asp.net core app, but of course this may raise up security concerns (though not sure what those would be).

Looking for ideas, advice, opinions, etc on such Auth models in a hybrid system such as electron.net.

[FlorianRappl]

Can you scrabble together a repo that showcases roughly what you want? Then I can take over and see what to do to make this dream come true!

[domingoladron]

I will do so today. Cheers for the assist.

Here's the challenges as I see them.

• with electron, you can do so reasonably easily as per the following tutorial. This is for Auth0, but the concept for most any identity provider would be similar https://auth0.com/blog/securing-electron-applications-with-openid-connect-and-oauth-2/

• For asp.net core, clearly you can do so over a proper https endpoint (with a valid cert). I have this working fine as a web server
  https://auth0.com/blog/what-is-blazor-tutorial-on-building-webapp-with-authentication/

The issue is that the blazor app running in electron.net is either http by default or even if you make it use https, you have the issue of a self-signed cert in your embedded blazor app.

The only way I can imagine this working would be to login using electron, but of course now you would need a means of

• triggering this logic on electron app start to make the user auth first and foremost
• ensuring asp.net core could fetch the correct data from electron to construct an IUserPrincipal which asp.net core could use to validate the authenticated user.

I might be overthinking this, and thus why I'm raising the question here: to see if anyone has faced this or has opinions on the best and most secure way to handle this.

I'll put some code together today and fwd the repo through.

[domingoladron]

Okay, so after attempting to build out an example of the source code I was after, I noted something in the above tutorial for an electron app which I had not noted previously. I was under the erroneous impression (not sure why I assumed this) that when the electron app called Auth0 (or whatever identity provider) it was using https for its callback url, which is not so (or at least not in the above example).

Search for the Allowed Callback URLs field and put the following URL as its value:

http://localhost/callback

Once done, Auth0 will invoke your allowed callback URL to take your users back to your application and inform it about the outcome: was authentication successful or not? For security reasons, Auth0 will only call URLs registered in the Allowed Callback URLs field. Despite the URL structure, you don't need to have an actual server listening to it; you just need to have your Electron application listening to it, as you will learn later on.

Realising that the electron app (be it electon js or electron.net) is just listening on http for the auth response anyway, I assumed there was very little value in attempting to bring electron into the mix since it was no more or less secure than letting the blazor app handle authentication on http. So, I simply focused on getting the blazor app inside to talk to Auth0. I was able to do so by using the blazor app's url port on localhost as the redirect url when Auth0 had completed authentication (localhost:{portnumber} is where the auth token will be provided back to your app)

So, I simply deicded to treat the embedded blazor app in my electron.net app as if it were a standard web app and Auth0 setup to act accordingly. To test and debug this, I ran the app as a normal web app, got the auth0 authentication working as per their instructions, and then tweaked it by running it up inside electron.net. I just needed the embedded asp.net core app's localhost:{portnumber} to be available in Auth0 as one of my allowed callback paths.

Now, you'd think at this point it would be quite easy, but no. What I found was that using http vs https matters a LOT to asp.net core in regards to authentication, and disabling https in authentication (particularly as related to cookies) is NOT as straightforward as you might think. After much googling and testing, I found the sweet spot for my program.cs and the cookie setup required:

        builder.Services.Configure<CookiePolicyOptions>(options =>
        {
            options.MinimumSameSitePolicy = SameSiteMode.Unspecified;
            options.Secure = CookieSecurePolicy.SameAsRequest;
        });

This allowed the proper cookies to be retrieved / set as related to authentication.
Is this the most secure way of doing this? I am keen to hear feedback. There are other avenues which can be explored, but each of them has its own peccadilloes and gotchas.

Feedback and comments most welcome.

[FlorianRappl]

Since you communicate with your localhost there is no point in HTTPS anyway. The secure tunnel only makes sense when going outside.

Glad you got a working solution!

[LapinskasL]

@domingoladron Thanks for the solution. I'm having trouble understanding what you meant by

I just needed the embedded asp.net core app's localhost:{portnumber} to be available in Auth0 as one of my allowed callback paths.

What does the code for that look like? Maybe you'd be able to share the authentication code in full? I'm working on authorizing an MVC app with Electron.NET.

Also, it was pleasant to read your articulation. You're a great writer.

[domingoladron]

Hey there,

Cheers for the nice reply. It's been a wee while, so give me a day or so to dust off that code and get it running again, but yes, I think I can help.