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

[ZacariasIra]

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: Feature Request: no-browser option for headless environment #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

[darrelmiller]

Thanks for the feedback. I have been successful in getting brokered auth to work following these instructions https://learn.microsoft.com/en-us/entra/msal/dotnet/acquiring-tokens/desktop-mobile/linux-dotnet-sdk-wsl?tabs=ubuntudep Although those instructions recommend an older version of libwebkit2gtk that isn't available.

Can you confirm if you are trying this in the Microsoft tenant, or some other tenant? Brokered auth is the only allowed option in the Microsoft tenant. I will follow up on the browser fallback in non-msft tenants. I thought that was working.

[ZacariasIra]

Thanks for the quick reply and the pointer to the MSAL broker docs!

Yes, this is in the Microsoft tenant (EMU account, accessed via VS Code Remote SSH into an Azure Linux 3.0 Kandor container on an Ubuntu 24.04 VM).

I've spent significant time trying to get brokered auth working. Here's what I found:

Inside the container (Azure Linux 3.0)

1. libwebkit2gtk-4.1 is not in Azure Linux repos. I was able to install it from openSUSE Leap 15.5 RPMs (libwebkit2gtk-4_1-0, libjavascriptcoregtk-4_1-0, plus ICU 73 from Fedora 39, libavif, dav1d, rav1e, aom, libmanette). After resolving ~15 transitive dependencies, msalruntime.so loads successfully.

2. However, MSALRUNTIME_Startup() fails because the microsoft-identity-broker service is not running. Installing the broker (RHEL 9 RPM) fails because it requires:

   • A running gnome-keyring (secret service) on D-Bus
   • Java 11 (crashes on Java 21 with IllegalAccessError)
   • A systemd context (STATE_DIRECTORY env var)

On the host Ubuntu 24.04 VM

Same issues. Even on a full Ubuntu VM with libwebkit2gtk-4.1, gnome-keyring, and microsoft-identity-broker installed:

• The broker crashes with IllegalAccessError on Java 21 (Ubuntu 24.04's default). It was built for Java 11.
• When started manually (outside systemd), it crashes with STATE_DIRECTORY is NULL.
• When started via systemctl, the gnome-keyring integration requires a desktop session.

Conclusion

The brokered auth path requires a fully managed Linux desktop enrolled in Intune with Java 11, systemd, gnome-keyring, and a display server. This doesn't work for:

• Remote dev containers (Kandor)
• Headless VMs accessed via SSH
• Modern Ubuntu VMs (Java 21 incompatibility)

Since brokered auth is required for the Microsoft tenant, when using Copilot inside remote dev environments, it is not possible to use WorkIQ.

Request

Could you please consider supporting device code flow for the Microsoft tenant? This would enable authentication in any environment by simply visiting a URL and entering a code — no broker, keyring, or display server needed. This is the same flow used by az login and gh auth login, which both work perfectly in these environments.

[ZacariasIra]

FYI @karsubr

[sw23]

@darrelmiller Our team would like to request device code flow as well. Our primary development environment does not support browser-based brokered auth and we rely on device code flow for several services. Microsoft has blocked device code flow by default, and our users go through a training and monthly attestation confirming that we must use it.