An Extension API to initiate an OAuth2 authentication process using a "popup" browser window instead of opening a new tab for the same

[aadarshp31]

I am creating a Vs Code web extension with OAuth2 based authentication (similar to Github Authentication in VS Code). I'm using vscode.env.openExternal to initiate the login process, which opens a new tab. Is there another option to open the same process in a popup window using VS Code's Extension API? Github Authentication uses a popup window for the same. I wasn't able to find the particular VS Code's Extension API.

Requests

1. Provide an Extension API for opening OAuth2 links in a popup window instead of opening a new tab, so the user doesn't have to leave the vscode.dev's browser tab while trying to authenticate. The whole authentication, redirection, and URL capture by vscode's URI handler should happen without switching to another tab.

What seems to be the issue?

• I'm using vscode.env.openExternal to initiate the login process, which opens a new tab. This forces the user to leave the current vscode.dev's context and hence ruining the user experience. On the other hand, the Popup window for OAuth2 is a very popular pattern for authentication, which most of the users are already familiar with, so that pattern would make things easier for the users.

Version: 1.63.2 Commit: 899d46d82c4c95423fb7e10e68eba52050e30ba3 User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36 Embedder: vscode.dev

[TylerLeonhardt]

@jrieken I would love this. Currently this works on vscode.dev because we specify a few specific Uris in the embedder that should open in a pop up but it would be nice to have a general solution for this that works for Desktop as well.

[aadarshp31]

Is there any update on this feature request?

[aadarshp31]

Any timeline for this feature?

[jrieken]

This is something that's happening in Electron. Adding @deepak1556 to see if that can be controlled

[deepak1556]

On desktop, openExternal call will delegate to the OS generic path handlers XDGOpen on linux, OpenURL on macOS, ShellExecuteW on windows and these open applications that are registered to handle the provided path. We might be able to pass additional arguments to the registered application but I don't see a way forward for this issue on desktop in a platform agnostic way.

[aadarshp31]

We might be able to pass additional arguments to the registered application but I don't see a way forward for this issue on desktop in a platform

Since "Github Authentication" uses a popup window for the same. So it should be possible to expose the same functionality for other extensions as well.

Also, providing an argument for openExternal to handle various ways to open a link should be a good way to not break previous use cases (i.e. opening in a new tab for browser vs popup window).

but I don't see a way forward for this issue on desktop in a platform agnostic way.

I also think that the popup window will be a better solution anyways for OAuth-related procedures whether done on the desktop or the web client.

[deepak1556]

For desktop, the application and runtime does not control which external application gets launched to handle a url, so it is hard for application to add the right set of arguments that can control the behavior (ex: browser), also not all browsers have a cli way to create new windows. I think the proposed feature request can be attempted from the point of web embedding scenario where the behavior of openExternal is different.

[aadarshp31]

feature request can be attempted from the point of web embedding scenario

By web embedding sceanario you mean the vscode.dev only right @deepak1556?

for desktop VS Code it is fine to open it in a new tab as it handles it right now. It's vscode.dev environment where we require popup window functionality. That way we'll be able to avoid the not-so-great context switching between browser tabs while doing some work on vscode.dev

we specify a few specific Uris in the embedder that should open in a pop up

Based on what @TylerLeonhardt mentioned above.

How about if we can provide a way to register Uris in the extension src itself as we do for URI Handlers via vscode.window.registerUriHandler ?

[deepak1556]

By web embedding sceanario you mean the vscode.dev only right

Yes that is correct

[aadarshp31]

we specify a few specific Uris in the embedder that should open in a pop up

Based on what @TylerLeonhardt mentioned above.

How about if we can provide a way to register Uris in the extension src itself as we do for URI Handlers via vscode.window.registerUriHandler ?

Can this be the way to move forward with this feature request?

[aadarshp31]

Any update on my previous suggestion?

[aadarshp31]

Hi Team, Please let me know if more information is required for this feature request. I'm desperately waiting for this request as this will greatly enhance the User Experience for extension development.

[TylerLeonhardt]

I've just read through this issue again and I think I totally misread the request. The request has nothing to do with VS Code Desktop (which we should still rely on the browser for for OAuth urls) but instead allow other OAuth flows to re-use the cool pop-up experience that we have with Microsoft and GitHub auth today in vscode.dev.

This is a vscode.dev + VS Code API feature request, I guess.

[TylerLeonhardt]

@joaomoreno that pop up that we have only shows for "trusted" sites. I'm wondering if there's a way to have the pop up but make it still "not trusted" just as tabs that are opened in new tabs are opened today?

One problem I foresee is that the site needs to be "trusted" for us to auto-close the pop up so the best we could do here is that the popup stays around and you have to close it manually.

[TylerLeonhardt]

@aadarshp31 what OAuth provider is this?

[aadarshp31]

Hi @TylerLeonhardt! Thanks for having a look at this issue again 😄

@aadarshp31 what OAuth provider is this?

We’re working in presently integrating with Zoho OAuth2.

[Chiramisu]

A lingering popup would be most unfortunate. Not an acceptable solution IMO. However, if the session was valid for an extended period of time of no less than one month, then it would at least be less insufferable.

[aadarshp31]

if the session was valid for an extended period of time

Hi @Chiramisu Yes, the session is supposed to be for an extended period (only expiring when the user logs out). Although even if the sign-in time expires, the user can terminate the popup window manually.

Note: Just to be clear, the popup window will be used for the authentication process via OAuth2, hence the popup window (browser) will be closed once the user is signed-in successfully or rejects the sign-in process altogether. So there will be no lingering popup window (browser).

[aadarshp31]

Also, if we can support closing the web popup window using our vscode extension's code, it will be an excellent boost for User Experience. Currently, even if we open a link in a browser using our extension, we can't close the tab programmatically.

[aadarshp31]

@joaomoreno that pop up that we have only shows for "trusted" sites. I'm wondering if there's a way to have the pop up but make it still "not trusted" just as tabs that are opened in new tabs are opened today?

One problem I foresee is that the site needs to be "trusted" for us to auto-close the pop up so the best we could do here is that the popup stays around and you have to close it manually.

@TylerLeonhardt is there any plans for this feature support for auth process other than Github and Microsoft authentication?

[TylerLeonhardt]

No plans to do that at this time.