Bug: WAM IncorrectConfiguration error prevents authentication on Windows (IsBrokerEnabled=true incompatible with http://localhost redirect URI)
Nobody has claimed this yet.
- Dominant language
- PowerShell
- Stars
- 1k
- Forks
- 132
- Avg merge
- 5d 19h
- Merged PRs (30d)
- 6
Description
Bug Report: WAM IncorrectConfiguration Error Prevents Authentication on Windows
Summary
Authentication always fails on Windows due to a MSAL WAM broker misconfiguration. The app has IsBrokerEnabled: true but uses RedirectUri: http://localhost, which is incompatible with WAM broker flows. This causes an infinite loop of auth popups that never succeed, and tokens are never cached.
Environment
- OS: Windows (win32-x64)
- Package:
@microsoft/workiq@latest(vianpx) - Tool: GitHub Copilot CLI with WorkIQ MCP plugin v1.0.0
- Node: via npx
Steps to Reproduce
- Install the WorkIQ plugin in GitHub Copilot CLI
- Run any WorkIQ command, e.g.:
npx @microsoft/workiq@latest --log-level Debug ask -q "test" - Observe repeated auth popups that never complete, followed by an error
Debug Output
info: Microsoft.WorkIQ.Auth.ClientAppFactory[0]
Configuring authentication for Windows with broker support
dbug: Microsoft.WorkIQ.Auth.ClientAppFactory[0]
Windows AppConfig: {
"ClientId": "ba081686-5d24-4bc6-a0d6-d034ecffed87",
"RedirectUri": "http://localhost",
"TenantId": "",
"IsBrokerEnabled": true,
"IsDefaultPlatformLoggingEnabled": false,
"LogLevel": "Info",
"ClientName": "",
"ClientVersion": ""
}
dbug: Microsoft.WorkIQ.Auth.InteractiveAuthProvider[0]
Starting authentication flow
dbug: Microsoft.WorkIQ.Auth.InteractiveAuthProvider[0]
Scopes requested: https://graph.microsoft.com/.default
dbug: Microsoft.WorkIQ.Auth.AccountManager[0]
Found 0 cached account(s)
dbug: Microsoft.WorkIQ.Auth.AccountManager[0]
Broker enabled on Windows, using OperatingSystemAccount sentinel
dbug: Microsoft.WorkIQ.Auth.InteractiveAuthProvider[0]
Silent authentication failed with MsalUiRequiredException: WAM Error
Error Code: 3399614476
Internal Error Code: 557973645
dbug: Microsoft.WorkIQ.Auth.InteractiveAuthProvider[0]
Launching interactive authentication flow
Error: WAM Error
Error Code: 3399614468
Error Message: IncorrectConfiguration
WAM Error Message: (pii)
Internal Error Code: 508634081
See troubleshooting: https://aka.ms/msal-net-wam
Root Cause
WAM broker requires a redirect URI in the format:
ms-appx-web://microsoft.aad.brokerplugin/{clientId}
The app is configured with http://localhost as the redirect URI, which is not valid for WAM broker flows. As a result:
- Silent token acquisition fails (0 cached accounts)
- Interactive auth popup is launched
- WAM rejects the flow with
IncorrectConfiguration - No token is ever cached
- Every subsequent call repeats the cycle — causing repeated auth popups for the user
Specifying --account explicitly does not resolve the issue.
Expected Behavior
Authentication should complete successfully on first launch, cache the token, and subsequent calls should use the cached token silently.
Suggested Fix
Either:
- Option A: Update the WAM redirect URI to
ms-appx-web://microsoft.aad.brokerplugin/ba081686-5d24-4bc6-a0d6-d034ecffed87(and register it in the Azure AD app registration) - Option B: Disable WAM broker (
IsBrokerEnabled: false) and fall back to a browser-based interactive auth flow, which works correctly withhttp://localhost
References
- MSAL.NET WAM troubleshooting: https://aka.ms/msal-net-wam
- WAM redirect URI requirements: https://learn.microsoft.com/en-us/entra/msal/dotnet/acquiring-tokens/desktop-mobile/wam
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the Windows AppConfig and the authentication flow that enables WAM, then compare its RedirectUri and IsBrokerEnabled values with the MSAL.NET WAM requirements in the linked documentation. Verify that Windows authentication completes without repeated popups, caches a token, and uses silent authentication on subsequent calls.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- node.js
- Domain
- authentication, cli
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100