macOS: workiq mcp/ask fails with AADSTS530084 — interactive auth is not device-bound (token protection)

macOS: workiq mcp / workiq ask fails with AADSTS530084 — interactive auth is not device-bound (token protection)

Summary

On a macOS device whose tenant enforces the Conditional Access policy "Require token protection for sign-in session", the WorkIQ CLI cannot authenticate. workiq mcp exits immediately (MCP host reports MCP error -32000: Connection closed) and workiq ask fails after an interactive browser login with AADSTS530084.

The CLI performs an interactive browser / loopback auth-code flow, which yields a token that is not bound to the device. Entra's token-protection control then rejects it — even though the device is Compliant and a valid device PRT exists.

Environment

• WorkIQ CLI version: 0.4.0.16790
• Platform: macOS (osx-arm64)
• App name: Work IQ CLI
• App id: ba081686-5d24-4bc6-a0d6-d034ecffed87
• Tenant: Microsoft (72f988bf-86f1-41af-91ab-2d7cd011db47)

Error

Error Code: 530084
App name: Work IQ CLI
App id: ba081686-5d24-4bc6-a0d6-d034ecffed87
Device platform: macOS
Device state: Compliant

(AADSTS530084 = Conditional Access "Require token protection for sign-in session".)

Root cause analysis

Token protection requires the access/refresh token to be cryptographically bound to the device via the Microsoft SSO broker (msalruntime → Company Portal SSO extension → device PRT). Verified on the affected machine:

• Microsoft Enterprise SSO plug-in com.microsoft.CompanyPortalMac.ssoextension (v5.2604.1) is active.
• Platform SSO is registered (registrationCompleted: true) with a valid, non-expired PRT advertising token binding (urn:aad:tb:update:prt/.default).
• The CLI ships msalruntime_arm64.dylib (the broker runtime).

Despite this, the CLI does not route through the broker — it falls back to interactive browser auth, producing a non-device-bound token → 530084. On macOS, MSAL's broker requires the caller to be a signed .app bundle with a registered msauth.<bundleid> broker redirect URI; a node-launched single-file CLI binary doesn't meet that, so MSAL silently falls back to the browser.

Impact

WorkIQ CLI and the WorkIQ MCP server are unusable on macOS for any tenant that enforces token protection (a common internal Microsoft CA policy). The local MCP server simply fails to connect.

Requested fix

Engage the macOS broker (msalruntime / Company Portal SSO extension) for token acquisition so issued tokens are device-bound and satisfy token protection. Concretely:

• Configure MSAL with WithBroker(new BrokerOptions(BrokerOptions.OperatingSystems.OSX)) and a broker redirect URI of the msauth.<bundleid> form.
• Ship/sign the macOS CLI such that the broker can validate the caller's bundle identity, and register the broker redirect URI on app ba081686-5d24-4bc6-a0d6-d034ecffed87.

Workarounds (current)

• Run the CLI on Windows, where MSAL uses WAM (broker) by default and tokens are device-bound.
• Use a broker-capable client (Edge / Teams / Office) for M365 Copilot until the CLI supports broker auth on macOS.

Repro

1. On a macOS device in a tenant enforcing "Require token protection for sign-in session", with no cached WorkIQ token (~/.workiq.json contains only the EULA flag).
2. Run workiq ask -q "hello" (or start workiq mcp).
3. Complete the interactive browser sign-in.
4. Observe AADSTS530084; the MCP server connection closes.

Reproduce with workiq ask -q "hello" and workiq mcp on the affected macOS setup, starting from the authentication entry points and the shipped msalruntime_arm64.dylib; ~/.workiq.json is the stated cache location. Done means authentication uses the macOS broker and both commands succeed under token protection without AADSTS530084.