macOS Browser Auth Fallback Not Applied to Blueprint Authentication Paths

[sellakumaran]

a365 setup blueprint fails on macOS 15.x with a PlatformNotSupportedException even after PR #290
introduced a device code fallback for browser auth failures. The fix in #290 only patched
AuthenticationService.AuthenticateInteractivelyAsync, but BlueprintSubcommand has two separate
authentication paths that bypass AuthenticationService entirely and directly use MsalBrowserCredential
without any device code fallback.

Symptoms

The user sees the following in the output before the command fails:

IMPORTANT: You must grant consent for all required permissions.
Successfully authenticated to Microsoft Graph!
Successfully authenticated to Microsoft Graph
Opening browser for authentication...
WARNING: Browser authentication is not supported on this platform: macOS 15.3.1
WARNING: Could not retrieve current user for sponsors field: Browser authentication is not supported on this platform (macOS 15.3.1)
Opening browser for authentication...
WARNING: Browser authentication is not supported on this platform: macOS 15.3.1
ERROR: Failed to acquire MSAL Graph access token
ERROR: Failed to extract access token from Graph client
ERROR: Failed to create agent blueprint
ERROR: Microsoft Graph API operation failed: Create Agent Blueprint
Blueprint creation failed.

Root Cause

PR #290 added the PlatformNotSupportedException → device code fallback inside
AuthenticationService.AuthenticateInteractivelyAsync. However, BlueprintSubcommand has two
authentication paths that never call AuthenticationService:

Gap 1 — AcquireMsalGraphTokenAsync (no fallback)

BlueprintSubcommand.AcquireMsalGraphTokenAsync creates MsalBrowserCredential and calls
GetTokenAsync directly. When MSAL throws PlatformNotSupportedException on macOS, it is
wrapped as MsalAuthenticationFailedException by MsalBrowserCredential, but the caller only
has a generic catch (Exception) that logs the error and returns null. There is no fallback
to device code flow.

Gap 2 — InteractiveGraphAuthService + lazy token acquisition

BlueprintSubcommand.GetAuthenticatedGraphClientAsync delegates to InteractiveGraphAuthService,
which creates a MsalBrowserCredential and passes it to the GraphServiceClient constructor.

The critical issue: GraphServiceClient acquires tokens lazily — only when the first actual
Graph API call is made. The GraphServiceClient constructor always succeeds, which causes
InteractiveGraphAuthService to log "Successfully authenticated to Microsoft Graph!" prematurely
and return a client backed by a non-functional credential.

The try/catch block in InteractiveGraphAuthService.GetAuthenticatedGraphClientAsync never fires
for PlatformNotSupportedException because the exception surfaces later, from inside the Graph SDK,
when an API call is attempted. At that point there is no recovery path — the credential is already
baked into the GraphServiceClient instance with no fallback.

This is also a code duplication problem: the device code fallback logic exists in
AuthenticationService but must now be replicated (or properly centralized) for every code path
that uses MsalBrowserCredential directly.

Affected Files

File	Issue
Commands/SetupSubcommands/BlueprintSubcommand.cs	AcquireMsalGraphTokenAsync — no device code fallback
Services/InteractiveGraphAuthService.cs	No device code fallback; eagerly logs success before token is acquired

Fix

Fix 1 — AcquireMsalGraphTokenAsync

Add a catch for MsalAuthenticationFailedException with inner PlatformNotSupportedException.
On macOS (or any platform where browser auth is unsupported), fall back to DeviceCodeCredential
using the same clientAppId and tenantId.

Fix 2 — InteractiveGraphAuthService.GetAuthenticatedGraphClientAsync

Before constructing the GraphServiceClient, eagerly acquire a token with MsalBrowserCredential
to detect platform support at construction time. If MsalAuthenticationFailedException with inner
PlatformNotSupportedException is caught, fall back to DeviceCodeCredential and build the
GraphServiceClient with that credential instead. This ensures the "Successfully authenticated"
log only appears after authentication has actually succeeded.

Related

• PR fix: fall back to device code when browser auth fails on macOS #290 — fix: fall back to device code when browser auth fails on macOS (partial fix)
• Issue a365 setup all fails on macOS 15.x with PlatformNotSupportedException during authentication #291 — original macOS 15.x auth failure report

[github-actions]

[AUTO-TRIAGE] Team Assistant Triage

This issue has been automatically analyzed and triaged.

AI Decision Reasoning: Type: Classified as 'bug' because the issue describes a failure in the authentication flow on macOS, which is unexpected behavior and prevents the command from functioning as intended.
Priority: Assigned P1 because the issue blocks a critical functionality (blueprint creation) on macOS, with no workaround available for affected users. [Security issue detected: The issue highlights authentication failures due to unsupported browser-based authentication on macOS, which could lead to improper handling of credentials and potential exposure or misuse of authentication flows, making it a security-related concern.]
Copilot: Security issues require human review and should not be auto-fixed
Assignment: Security issue assigned to security lead. The issue highlights authentication failures due to unsupported browser-based authentication on macOS, which could lead to improper handling of credentials and potential exposure or misuse of authentication flows, making it a security-related concern.
Labels: Applied labels bug, P1, security based on issue type and priority

Labels and assignee have been applied based on this analysis.

[github-actions]

[AUTO-TRIAGE] Results

Classification: bug
Priority: P1
Confidence: 100.0%

Recommended Assignee: @sellakumaran

Analysis:
type rationale: Classified as 'bug' because the issue describes a failure in the authentication flow on macOS, which is unexpected behavior and prevents the command from functioning as intended.

priority rationale: Assigned P1 because the issue blocks a critical functionality (blueprint creation) on macOS, with no workaround available for affected users. [Security issue detected: The issue highlights authentication failures due to unsupported browser-based authentication on macOS, which could lead to improper handling of credentials and potential exposure or misuse of authentication flows, making it a security-related concern.]

copilot rationale: Security issues require human review and should not be auto-fixed

assignment rationale: Security issue assigned to security lead. The issue highlights authentication failures due to unsupported browser-based authentication on macOS, which could lead to improper handling of credentials and potential exposure or misuse of authentication flows, making it a security-related concern.

labels rationale: Applied labels bug, P1, security based on issue type and priority

[SUGGESTION] Suggested Approach

1. Refactor BlueprintSubcommand.AcquireMsalGraphTokenAsync to use AuthenticationService.AuthenticateInteractivelyAsync instead of directly creating MsalBrowserCredential. This ensures the device code fallback logic introduced in PR fix: fall back to device code when browser auth fails on macOS #290 is applied consistently across all authentication paths. Update the relevant method in src/BlueprintSubcommand.cs.
2. Add a device code fallback directly within AcquireMsalGraphTokenAsync for cases where PlatformNotSupportedException is thrown by MsalBrowserCredential. This can be achieved by catching MsalAuthenticationFailedException and invoking the device code flow using the MSAL library's AcquireTokenWithDeviceCodeAsync method.
3. Update the error handling in BlueprintSubcommand.AcquireMsalGraphTokenAsync to specifically catch PlatformNotSupportedException or MsalAuthenticationFailedException instead of using a generic catch (Exception). Log detailed error messages and ensure fallback mechanisms are triggered appropriately.
4. Write unit tests for BlueprintSubcommand.AcquireMsalGraphTokenAsync to validate the fallback behavior on macOS. Add these tests to src/Tests/Microsoft.Agents.A365.DevTools.Cli.Tests/MockToolingServer or a new test file focused on BlueprintSubcommand to simulate PlatformNotSupportedException and verify the device code flow is executed.
5. Update the documentation in docs/authentication.md (or create a new section if it doesn't exist) to clarify how authentication works on macOS, including the device code fallback mechanism. Provide examples of expected behavior and troubleshooting steps for users encountering similar issues.

---

Generated by TeamAssistant Auto-Triage powered by GitHub Models