Entra ID authentication fails if the executable is executed as a different user due to a longstanding bug in `WebAuthenticationCoreManager`

[Fulgen301]

Relevant area(s)

WinGet CLI, PowerShell Module, COM API

Relevant command(s)

winget search, winget install, winget download, winget list, winget upgrade

Brief description of your issue

winget uses WebAuthenticationCoreManager to obtain an Entra ID token for to authenticate with sources requiring authentication. However, that API does not support the process user being a different one than the session user, which is the case when winget is "elevated" via UAC as a standard user, which spawns the process with the administrator user's credentials, due to a longstanding bug in that API; somewhere along the chain from winget over the AADBrokerPlugin to CloudAP, something screws up and fails with STATUS_NO_SUCH_LOGON_SESSION.

If the application is run as the same standard user with administrator rights by creating a token for the standard user via LogonUserExExW or LsaLogonUser and passing BUILTIN\Administrators in the extra groups parameter, or by simply using a user with administrative rights in the first place, the problem does not occur, so it seems to be sensitive to the process having a different user.

This has been reported multiple times both in this repository, though with more obscure use cases (ssh, CI) - see #5398 and #698, as well as in other Microsoft products using this API (microsoft/vscode#241391). It does not only affect the standalone winget executable, but also the COM API, and presents a blocker for enterprise adoption of winget in managed environments that can only be mitigated by playing tricks with LSA to obtain a token with administrative rights bolted onto it. This severely cripples winget's usability with private repositories containing files that shouldn't be available to anyone in managed environments where support staff needs to be able to install applications on systems where users do not possess administrator rights.

I can't speak to why this API issue has been unfixed for over five years, nor is it something winget can fix on its own as the problem is somewhere in the operating system; but with repository authentication being so fundamentally limited, the WAM team seemingly being unable to fix this longstanding bug (I can't tell, Windows does not provide a usable bugtracker for its APIs), winget should, in my eyes, switch to a different authentication API for Entra ID.

Steps to reproduce

1. Add a source to winget that requires Entra ID authentication.
2. Create a standard user without administrator group membership.
3. Create an elevated shell session. UAC will require you to enter administrator account credentials. The shell process will now run as that administrator user.
4. Run any winget command, like search, against that source. It will fail with 0x80070520.

Expected behavior

It should work.

Actual behavior

It fails due to a bug in WebAuthenticationCoreManager:

Fehler beim Öffnen der Quelle(n): Probieren Sie den Befehl "source reset" aus, wenn das Problem weiterhinbesteht.
Unterwarteter Fehler beim Ausführen des Befehls:
0x80070520 : Eine angegebene Anmeldesitzung ist nicht vorhandne. Sie wurde gegebenenfalls bereits beendet.

Environment

Windows-Paket-Manager v1.28.240
Copyright (c) Microsoft Corporation. Alle Rechte vorbehalten.

Windows: Windows.Desktop v10.0.26200.8246
Systemarchitektur: X64
Paket: Microsoft.DesktopAppInstaller v1.28.240.0

[Fulgen301]

An alternative for winget that circumvents the API bug could also be to do the inverse of what sudo does: winget could spawn an executable via IShellDispatch2::ShellExecute as the original user that spins up a RPC server, receives the authentication request, does the WebAuthenticationCoreManager calls and returns back the token / any errors (though spawning a helper process is not as easy for the COM API, being an in-proc DLL, and I don't know whether this works for the packaged version)