[RFE] Support authentication plugin to override getToken() and setToken()

[lijianzhi01]

Current situation

Get or set token are either from oidc sign in or input token by user.

1. Microsoft authentication will require redirect or popup. In desktop app situation, it is not supported. Organization might set redirect to http://localhost:xxxx/blank, but desktop app only cannot load that URL. You might use popup way to authenticate, but now it is not supported by Headlamp, too.
2. If token is expired, headlamp redirect to landing page. User lost their operation context. They might spend lots of time to find out what context they were after sign in again.

Impact

1. Define authentication processes. No matter redirection, popup way, or any other ways, user can manage by themselves.
2. Token might be expired, sign in user immediately inside getToken() without break user's operation.

[illume]

We had some discussions on how to do this, the pros and cons of different approaches. I'll try to summarize that here.

Flow for authentication using users browser.

1) open users browser at the auth page, including the URL for redirect to the backend server.exe localhost:xxx/authreturn 2) localhost:xxx/authreturn is open in the users browser, this will save the token inside the server.exe process so that it can be accessed by the Electron app. 3) The Headlamp electron app will then be able to take the token(by reading a route on the backend). [1] 4) Headlamp can become the focused window (the active window on top of the browser window).

[1] Between the 2nd and 3rd how will we know in headlamp that if the auth flow succeeded and now we have to start reading the token from the backend?

Part 3 is talking about reading a URL on the backend for the token. Headlamp can begin reading this backend URL as soon as the auth flow starts and that URL will return if the auth succeeds/fails as soon as it does.

Why not a popup within the Headlamp electron app?

Doing auth in an electron Headlamp popup can be a security issue for a number of reasons and also be a worse experience. By default Electron blocks popups, so that layer of defense would need to be lowered (there is an open PR to allow about:blank popups). One workaround for this problem would be to have an allowlist of domains to be trusted (to be managed somehow) which would be a build time configuration. However there are further issues. Having users type passwords into the app is not good, because passwords in general should be avoided. If a user uses their browser it can probably use the existing authentication infrastructure to avoid passwords. Finally, it is a better experience for the user to use their own (Edge) browser authentication they are used to that is able to authenticate with less friction and with perhaps more capabilities than what Electron (chromium based) supports.

[lijianzhi01]

I think there are two things need to be clear.

First, about [1].

I think Headlamp do not need to care about authentication flow. Let me explain how we designed our authentication flow. Take popup as example.

1. We designed landing page plugin. This plugin will launch authentication with MSAL by window.open(), which is popup way.
2. After user logon in, popup will be redirected to http://localhost:4466/blank. At this moment, MSAL finds out popup's url is http://localhost:4466/blank, it will close popup and store account's info into cookie.
3. Now, our plugin can get access token by MSAL.

In this way, only two things Headlamp need to do. One is setup an endpoint, http://localhost:4466/blank, which do nothing but return 200. It is just for call back. Second is allow us to overwrite getToken() and setToken(). We can get access in our way. And authenticate user without break operation's context when access token is expired.

Second, about popup.

Can headlamp open browser can be through window.open() inside MSAL?(https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/src/utils/PopupUtils.ts#L134) We do not care about open popup by electron window or edge window. Although, MSAL provides redirect, but we do not like this way. Because it will break user's operation that redirect to sign in page when access token expired.

User do not input password in popup, they will be authenticated by physical key.

[illume]

User do not input password in popup, they will be authenticated by physical key.

It's my understanding the electron app has a separate context than Edge. It asks the user to login more, and presents password based login because other authentication methods are not available to it. Did you already test the physical key auth works ok using the Electron app popup?

[joaquimrocha]

This is fixed now since #892 .