Summary
Would you consider adding a documented interaction policy to the aad token-acquisition contract? This would allow callers to reuse existing credentials or sessions silently while guaranteeing that AzureAuth will not display WAM dialogs, account pickers, browser UI, device-code instructions, terminal prompts, or other authentication UI.
This capability would be most useful if interaction policy could be controlled independently of authentication mode. Maintainers might choose syntax such as --interaction never|allowed, but the naming and implementation are intentionally left open.
I may have missed an existing supported invocation that provides this guarantee; if so, guidance would be appreciated.
Background and scenario
I am integrating AzureAuth into a downstream Git credential provider that runs in WSL and launches the Windows AzureAuth 0.9.5 executable. The concrete caller environment is configured for noninteractive credential acquisition using GIT_TERMINAL_PROMPT=0 and credential.interactive=never; some helper environments also use GCM_INTERACTIVE=Never as a separate compatibility signal.
The downstream helper translates these caller-specific settings before invoking AzureAuth. AzureAuth does not need to interpret Git-specific environment variables.
The desired outcome is to reuse an existing Windows credential or session silently when possible, never initiate authentication UI when interaction is forbidden, and return a machine-readable result that lets the caller decide what to do next.
Current behavior
From reading AzureAuth 0.9.5, my understanding is:
- The Windows default is broker followed by web.
- The broker flow selects a cached account, or
PublicClientApplication.OperatingSystemAccount, and first attempts cached/silent acquisition.
- If that attempt misses, the same broker flow invokes interactive WAM. The overall flow ordering may then continue to web.
AZUREAUTH_NO_USER with any nonempty value, or Corext_NonInteractive with the value 1, disables interactive authentication according to the immutable environment-value checks. On Windows this replaces the selected modes with IWA when the filter is applied. Generic cache handling may still occur, but WAM broker-backed silent acquisition is no longer retained.- The CLI exposes neither a public stop boundary after broker-silent acquisition nor a distinct interaction-required result; unsuccessful acquisition reaches the general CLI failure path.
I could not find a supported boundary in the current main snapshot de20930c34b3b86c8a0ed7bbdeeca3f662dae918: no-user handling still substitutes IWA, broker still transitions from silent to interactive, and failure still reaches the general CLI path.
For this integration, the available choices appear to be using the existing no-user controls and forgoing WAM broker-backed silent reuse, skipping AzureAuth, or retaining broker mode and risking interactive UI.
Requested behavior
Would it be possible to provide a documented interaction policy independent of authentication mode?
- Forbidden/never: Evaluate all applicable silent-capable stages across the selected modes, including broker-backed cache and the Windows OS account, while skipping every interactive stage.
- Allowed/default: Preserve current behavior.
When the next applicable step requires user interaction, AzureAuth would return a documented, machine-readable outcome equivalent to interaction_required. The exact exit code or JSON schema is not prescribed.
Ideally, callers could distinguish the interaction-required outcome from invalid arguments, launch/process failures, network or authentication failures, and cancellation. Silent exhaustion or failure should not automatically be classified as interaction-required, and that result should not imply that interaction would succeed.
Existing defaults and legacy environment behavior should remain unchanged unless maintainers intentionally define migration or precedence rules.
Why the existing controls are insufficient
The current no-user controls prevent interaction by replacing the requested modes with IWA. They cannot express “use broker-backed silent sources, but do not cross into broker UI.” MSAL’s documented WAM pattern provides the relevant silent-first boundary before interactive acquisition.
Suggested acceptance criteria
- A silent broker/cache hit succeeds.
- When further progress requires interaction, AzureAuth returns the documented interaction-required outcome without displaying UI.
- No interactive WAM UI, browser/web UI, device-code instructions, or terminal prompting occurs under the forbidden policy.
- Interaction-required is machine-distinguishable from other failure categories.
- Invocations without the new policy retain existing behavior.
- Tests are deterministic and do not depend on timing or detecting visible UI.
Scope
For this issue, I am only asking about the aad token-acquisition caller contract. Cache redesign, WSL process delegation or executable discovery, service identities, and effort estimates are out of scope.
This appears related to #460 because the Windows-side interaction contract would support that broader WSL delegation proposal, while WSL delegation itself remains out of scope here.
Summary
Would you consider adding a documented interaction policy to the
aadtoken-acquisition contract? This would allow callers to reuse existing credentials or sessions silently while guaranteeing that AzureAuth will not display WAM dialogs, account pickers, browser UI, device-code instructions, terminal prompts, or other authentication UI.This capability would be most useful if interaction policy could be controlled independently of authentication mode. Maintainers might choose syntax such as
--interaction never|allowed, but the naming and implementation are intentionally left open.I may have missed an existing supported invocation that provides this guarantee; if so, guidance would be appreciated.
Background and scenario
I am integrating AzureAuth into a downstream Git credential provider that runs in WSL and launches the Windows AzureAuth 0.9.5 executable. The concrete caller environment is configured for noninteractive credential acquisition using
GIT_TERMINAL_PROMPT=0andcredential.interactive=never; some helper environments also useGCM_INTERACTIVE=Neveras a separate compatibility signal.The downstream helper translates these caller-specific settings before invoking AzureAuth. AzureAuth does not need to interpret Git-specific environment variables.
The desired outcome is to reuse an existing Windows credential or session silently when possible, never initiate authentication UI when interaction is forbidden, and return a machine-readable result that lets the caller decide what to do next.
Current behavior
From reading AzureAuth 0.9.5, my understanding is:
PublicClientApplication.OperatingSystemAccount, and first attempts cached/silent acquisition.AZUREAUTH_NO_USERwith any nonempty value, orCorext_NonInteractivewith the value1, disables interactive authentication according to the immutable environment-value checks. On Windows this replaces the selected modes with IWA when the filter is applied. Generic cache handling may still occur, but WAM broker-backed silent acquisition is no longer retained.I could not find a supported boundary in the current main snapshot
de20930c34b3b86c8a0ed7bbdeeca3f662dae918: no-user handling still substitutes IWA, broker still transitions from silent to interactive, and failure still reaches the general CLI path.For this integration, the available choices appear to be using the existing no-user controls and forgoing WAM broker-backed silent reuse, skipping AzureAuth, or retaining broker mode and risking interactive UI.
Requested behavior
Would it be possible to provide a documented interaction policy independent of authentication mode?
When the next applicable step requires user interaction, AzureAuth would return a documented, machine-readable outcome equivalent to
interaction_required. The exact exit code or JSON schema is not prescribed.Ideally, callers could distinguish the interaction-required outcome from invalid arguments, launch/process failures, network or authentication failures, and cancellation. Silent exhaustion or failure should not automatically be classified as interaction-required, and that result should not imply that interaction would succeed.
Existing defaults and legacy environment behavior should remain unchanged unless maintainers intentionally define migration or precedence rules.
Why the existing controls are insufficient
The current no-user controls prevent interaction by replacing the requested modes with IWA. They cannot express “use broker-backed silent sources, but do not cross into broker UI.” MSAL’s documented WAM pattern provides the relevant silent-first boundary before interactive acquisition.
Suggested acceptance criteria
Scope
For this issue, I am only asking about the
aadtoken-acquisition caller contract. Cache redesign, WSL process delegation or executable discovery, service identities, and effort estimates are out of scope.This appears related to #460 because the Windows-side interaction contract would support that broader WSL delegation proposal, while WSL delegation itself remains out of scope here.