Redirect URI for Electron based app?

Hi,

I’m currently developing a desktop application using Electron. However, since Electron (in a simplified sense) simply opens an HTML file using the file:// protocol, I’m not sure what I should use as redirect URI in our Azure application.

Many OAuth tutorials online mention using localhost, but that’s unsuitable for production IMO.

One approach I tried which almost works is adding native as a platform in our app, which let’s us use https://login.microsoftonline.com/common/oauth2/nativeclient as redirect. I then listened to url changes in the Electron window for when the user is redirected to the above url. Lastly, I took the hash (which contains #id_token among other things) and manually redirected to our HTML page with the hash included.

This sort of worked, except userAgentApplication.acquireTokenSilent(graphAPIScopes) doesn’t work. Perhaps because of the absence of some Azure cookie? If I use acquireTokenRedirect, and then acquireTokenSilent, that works, but that requires the user to log in twice…

Do you have any suggestions for this situation?

Issue Analytics

State:
Created 5 years ago
Comments:5 (1 by maintainers)

Top GitHub Comments

1reaction

navyasriccommented, Jan 24, 2019

MSAL.js is designed to handle authentication using OpenID Connect flows in JS web applications. It does not support the code flow required by native applications. @willwull Closing this issue as the approach mentioned in above comment maybe more suitable for your scenario and it is not related to MSAL.js.

0reactions

justinwilabycommented, Jul 31, 2018

@willwull -

Yes that is correct. I did not use the msal library for 2 reasons:

I wanted to use a WebView and not an iframe
Taking on anther dependency for essentially building a url and registering callbacks seemed unnecessary in my case

In the case of the Botframework Emulator, we run an HTTP server as part of the startup sequence for, well, emulation. This server also used to deliver the empty page as the redirect_uri registered in Azure. Since the WebView is closed as soon as this page is loaded, the user never sees this page.

In your case, using a simple http server using native node APIs and spinning up this server when the user begins the Auth flow and terminating it when the flow completes would be the lightest and fastest implementation. Generator functions are an exquisite way to define multi-step asynchronous workflows so I’d recommend looking into this to determine if they are appropriate for your particular case.

If you need to get an access token in addition to an id_token, update the response type to response_type=id_token+code. the url will look like this:

https://login.microsoftonline.com/common/oauth2/authorize?response_type=id_token+code

I’ll be implementing JWT validation and Azure web service access using the access token this week on the jwilaby/AAD-token-validation and the jwilaby/azure-service-access branches. Feel free to follow along, comment and contribute!