Summary
On Windows, broker authentication can silently return a token for the operating system account even when that account does not match the preferred domain supplied through --domain.
I understand that --domain is documented as a preference for filtering cached accounts rather than a strict identity constraint. In a multi-account environment, however, falling back to the operating system account can select an identity unrelated to the requested domain. I could not find an AzureAuth option that retains broker authentication while making the preferred domain a strict constraint.
This report concerns account selection only; it does not request silent-only authentication or a change to the interaction policy.
Environment
- AzureAuth 0.9.5 Windows executable
- Windows 11 Enterprise, build 26200
- Windows Web Account Manager available
- Windows executable invoked from WSL2
- One work or school account configured as the operating system account
- A different account domain supplied through
--domain
The behavior was reproduced with AzureAuth 0.9.5. Released AzureAuth 0.9.6 (8ef1b8b00782bf20a51de078289819a79c3cba70) and main at de20930c34b3b86c8a0ed7bbdeeca3f662dae918 (inspected on 2026-08-27) retain the same Windows account-resolution behavior.
Reproduction
On a Windows host where the operating system account uses one domain and no unique cached account matches a different preferred domain, request an Azure DevOps access token through the broker:
azureauth.exe aad \
--client 872cd9fa-d31f-45e0-9eab-6e460a02d1f1 \
--tenant organizations \
--scope 499b84ac-1321-427f-aa17-267ca6975798/.default \
--domain <different-account-domain> \
--mode broker \
--output token
Do not publish the returned token. Decode its JWT claims locally only to identify the selected tenant and account.
Actual behavior
AzureAuth can complete without interaction and return a token for the operating system account, whose account domain differs from the value supplied through --domain.
In the observed case, the returned token represented the work or school account rather than an account matching the preferred domain. The downstream Azure DevOps operation then failed because the selected account did not have access to the target organization.
Request
Would the project consider supporting an optional strict account or domain constraint for callers that need deterministic identity selection?
For example, when such a constraint is requested and no unique cached account matches, AzureAuth could avoid silently returning the operating system account and instead require account selection or report that no matching account is available. The existing best-effort behavior of --domain could remain the default.
If an existing option already provides this behavior, guidance would be appreciated.
Source analysis
In AzureAuth 0.9.5, Broker.GetTokenInnerAsync() calls TryToGetCachedAccountAsync(preferredDomain) and substitutes PublicClientApplication.OperatingSystemAccount when that lookup returns null. TryToGetCachedAccountAsync() returns null when no cached account matches or when the match is not unique.
The current main branch preserves this Windows behavior in Broker.ResolveAccountAsync(). This appears to explain the observed selection, but I may be missing another supported account-selection mechanism.
Impact
On multi-account Windows hosts, a caller may receive a valid token for another signed-in account and discover the mismatch only through token inspection or a downstream authorization failure.
No credential material is included in this report.
Summary
On Windows, broker authentication can silently return a token for the operating system account even when that account does not match the preferred domain supplied through
--domain.I understand that
--domainis documented as a preference for filtering cached accounts rather than a strict identity constraint. In a multi-account environment, however, falling back to the operating system account can select an identity unrelated to the requested domain. I could not find an AzureAuth option that retains broker authentication while making the preferred domain a strict constraint.This report concerns account selection only; it does not request silent-only authentication or a change to the interaction policy.
Environment
--domainThe behavior was reproduced with AzureAuth 0.9.5. Released AzureAuth 0.9.6 (
8ef1b8b00782bf20a51de078289819a79c3cba70) andmainatde20930c34b3b86c8a0ed7bbdeeca3f662dae918(inspected on 2026-08-27) retain the same Windows account-resolution behavior.Reproduction
On a Windows host where the operating system account uses one domain and no unique cached account matches a different preferred domain, request an Azure DevOps access token through the broker:
Do not publish the returned token. Decode its JWT claims locally only to identify the selected tenant and account.
Actual behavior
AzureAuth can complete without interaction and return a token for the operating system account, whose account domain differs from the value supplied through
--domain.In the observed case, the returned token represented the work or school account rather than an account matching the preferred domain. The downstream Azure DevOps operation then failed because the selected account did not have access to the target organization.
Request
Would the project consider supporting an optional strict account or domain constraint for callers that need deterministic identity selection?
For example, when such a constraint is requested and no unique cached account matches, AzureAuth could avoid silently returning the operating system account and instead require account selection or report that no matching account is available. The existing best-effort behavior of
--domaincould remain the default.If an existing option already provides this behavior, guidance would be appreciated.
Source analysis
In AzureAuth 0.9.5,
Broker.GetTokenInnerAsync()callsTryToGetCachedAccountAsync(preferredDomain)and substitutesPublicClientApplication.OperatingSystemAccountwhen that lookup returnsnull.TryToGetCachedAccountAsync()returnsnullwhen no cached account matches or when the match is not unique.The current
mainbranch preserves this Windows behavior inBroker.ResolveAccountAsync(). This appears to explain the observed selection, but I may be missing another supported account-selection mechanism.Impact
On multi-account Windows hosts, a caller may receive a valid token for another signed-in account and discover the mismatch only through token inspection or a downstream authorization failure.
No credential material is included in this report.