Authentication fails on remote Linux containers (Azure Linux) - missing libwebkit2gtk + redirect URI mismatch

Description

WorkIQ MCP server (v0.4.0) fails to authenticate when running inside a remote Linux container (Azure Linux 3.0 / Kandor) accessed via VS Code Remote. The authentication flow hits two sequential blockers.

Environment

• OS: Microsoft Azure Linux 3.0 (container)
• Access: VS Code Remote SSH
• Node.js: v22.21.0
• WorkIQ: @microsoft/workiq 0.4.0
• .NET Runtime: 10.0.3
• MSAL: 4.81.0.0
• glibc: 2.38

Blocker 1: msalruntime.so fails to load (missing libwebkit2gtk)

Error: Unable to load shared library 'msalruntime' or one of its dependencies.
libwebkit2gtk-4.1.so.0: cannot open shared object file: No such file or directory
libjavascriptcoregtk-4.1.so.0: cannot open shared object file: No such file or directory

libwebkit2gtk is not available in Azure Linux package repositories (tdnf). Other dependencies (gtk3, libsoup, libsecret, atk, cairo-gobject, gdk-pixbuf2) can be installed but webkit2gtk cannot.

Workaround for Blocker 1

Creating stub shared libraries allows msalruntime.so to load:

cat > /tmp/stub.c << 'STUBEOF'
void __attribute__((constructor)) stub_init(void) {}
STUBEOF
gcc -shared -o /usr/lib64/libwebkit2gtk-4.1.so.0 /tmp/stub.c -Wl,-soname,libwebkit2gtk-4.1.so.0
gcc -shared -o /usr/lib64/libjavascriptcoregtk-4.1.so.0 /tmp/stub.c -Wl,-soname,libjavascriptcoregtk-4.1.so.0
ldconfig

Blocker 2: Redirect URI mismatch (after Blocker 1 is resolved)

Once msalruntime loads (with stubs), the broker cannot function properly, so MSAL falls back to system browser auth. This fails with:

Error: Only loopback redirect uri is supported, but
https://login.microsoftonline.com/common/oauth2/nativeclient was found.
Configure http://localhost or http://localhost:port both during app
registration and when you create the PublicClientApplication object.

The app is registered with RedirectUri: "https://login.microsoftonline.com/common/oauth2/nativeclient" (for broker auth), but the system browser fallback requires http://localhost. There is no config option to override this.

Additional context

• DOTNET_SYSTEM_NET_DISABLEIPV6=1 is also needed for the auth callback (IPv6 vs IPv4 mismatch with VS Code port forwarding)
• Token cache from another machine (msal_token_cache.dat) is not portable due to platform-specific encryption
• The trace log shows IsBrokerEnabled: true is hardcoded with no way to disable it
• Related: https://github.com/microsoft/work-iq/issues/46

Expected behavior

WorkIQ should support authentication in remote Linux containers, either by:

1. Falling back to http://localhost redirect URI when the broker is unavailable
2. Supporting device code flow as a headless authentication alternative
3. Making broker optional via config or environment variable (e.g., WORKIQ_DISABLE_BROKER=1)
4. Documenting required system packages for Linux environments that need the broker

Steps to reproduce

1. Deploy a container with Azure Linux 3.0 (no libwebkit2gtk available)
2. Connect via VS Code Remote SSH
3. Run npx -y @microsoft/workiq ask -q "test"
4. Observe msalruntime loading failure
5. After installing stubs for webkit2gtk, observe redirect URI mismatch error

Start by reproducing the failure with npx -y @microsoft/workiq ask -q "test" in an Azure Linux 3.0 container and review the trace log, including the hardcoded broker setting. Compare the broker and system-browser errors, then define one supported fallback—localhost redirect, device code, optional broker, or documented packages—with a successful remote authentication flow as done.