Current Situation
We built an Electron application that uses Web APIs guarded by Azure AD B2C. The authentication process happens as follows:
- User wants to log in
- Electron prepares the initial OIDC request (return type code with oidc scope included)
- Electron (main thread) opens system browser with the correct
b2clogin.comtenant - User enters credentials and is redirected on success (using a custom protocol e.g.
my-awesome-app://) - Electron app handles the redirect (new instance handling, URL parsing, all things work fine)
- Correctly parsed information is used to dispatch the last auth request (on the main process again)
- App receives auth token and user is logged in
All of this works without the need of embedded web-views and local web servers which handle localhost redirects. At least to my understanding we should adhere to the current state of the art regarding OIDC usage in native applications.
Problem
The above mentioned process works well - it only has one caveat: the browser window where the users enter their credentials stays open. As far as I can tell this happens because the browser dutifully redirects but never knows that it succeeded (the networking monitor of the browser will show a failure even though the redirect was handled by the OS).
As far as I know from inspecting the GitHub desktop application, the Slack desktop application as well as this .NET Console Application sample by Brock Allen this behavior is to be expected. The main problem with Azure AD B2C is that the identity provider never leaves the login form holding the entered credentials.
As far as I can see (and I have spent a lot of time on Google and the Microsoft Docs) there is no obvious way to change this behavior. The IDPs used by those apps navigate to another page and display a message to close the tab when the login succeeded. I tried to look for guidance in the MSAL documentation - as it is Microsoft's own library for this use case - but they don't appear to be considering custom protocols at all (apparently the usage of the system browser is even actively discouraged for UWP).
There was an attempt to offer an MSAL experience for Electron during a Microsoft Internship but the efforts appear to have been abandoned. It would have also used a new electron browser window within the same process which we actively try to avoid.
As far as I see the current 'best thing you can get' is to have the IDP navigate to a window which can not be used to extract credentials should the user forget to close it.
This leads to my main question: Is it possible to achieve this behavior with Azure AD B2C or are we forced to fall back to an 'embedded web-view' experience?
