a365 setup all admin-consent URL returns invalid_client in browser ("Try that again using a different browser")

[beyondszine]

Description

This seems similar yet differnet from #429
In this case, I am not getting error in the url but still getting the same 'Try that agin using a different browser' screen.

the url that lands:

https://entra.microsoft.com/TokenAuthorize?admin_consent=True
&tenant=...
&state=.....
&scope=https%3a%2f%2fgraph.microsoft.com%2fMail.ReadWrite+https%3a%2f%2fgraph.microsoft.com%2fMail.Send+https%3a%2f%2fgraph.microsoft.com%2fChat.ReadWrite+https%3a%2f%2fgraph.microsoft.com%2fUser.Read.All+https%3a%2f%2fgraph.microsoft.com%2fSites.Read.All+https%3a%2f%2fgraph.microsoft.com%2fFiles.ReadWrite.All+https%3a%2f%2fgraph.microsoft.com%2fChannelMessage.Read.All+https%3a%2f%2fgraph.microsoft.com%2fChannelMessage.Send

Expected behavior

No response

SDK Version

1.1.193+79f9a1eaf3

Language/Runtime

.net

OS

windows 11

How to Reproduce

run the a365 setup all or a365 setup blueprint --agent-name "myagent" command

Output

No response

Screenshots

No response

Code of Conduct

• I agree to follow the Microsoft Open Source Code of Conduct.

[beyondszine]

@biswapm / @sellakumaran any advice/suggestions here?

[github-actions]

[AUTO-TRIAGE] Team Assistant Triage

This issue has been automatically analyzed and triaged.

AI Decision Reasoning: Type: Classified as 'bug' because the user reports an unexpected error ('invalid_client') when running a specific command, indicating a failure in expected functionality.
Priority: Elevated to P1 due to security concern: The issue involves an OAuth-related error (invalid_client) during an admin consent flow, which could indicate a misconfiguration or potential security vulnerability in the authentication setup, such as improper client ID/secret handling or scope mismanagement.
Copilot: Security issues require human review and should not be auto-fixed
Assignment: Security issue assigned to security lead. The issue involves an OAuth-related error (invalid_client) during an admin consent flow, which could indicate a misconfiguration or potential security vulnerability in the authentication setup, such as improper client ID/secret handling or scope mismanagement.
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: 95.0%

Recommended Assignee: @sellakumaran

Analysis:
type rationale: Classified as 'bug' because the user reports an unexpected error ('invalid_client') when running a specific command, indicating a failure in expected functionality.

priority rationale: Elevated to P1 due to security concern: The issue involves an OAuth-related error (`invalid_client`) during an admin consent flow, which could indicate a misconfiguration or potential security vulnerability in the authentication setup, such as improper client ID/secret handling or scope mismanagement.

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

assignment rationale: Security issue assigned to security lead. The issue involves an OAuth-related error (`invalid_client`) during an admin consent flow, which could indicate a misconfiguration or potential security vulnerability in the authentication setup, such as improper client ID/secret handling or scope mismanagement.

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

[SUGGESTION] Suggested Approach

1. Check the OAuth configuration in the CLI codebase, specifically in the `src` directory. Look for the logic that generates the admin-consent URL, likely in a file related to authentication or setup, such as `src/Microsoft.Agents.A365.DevTools.Cli/Setup/Authentication.cs`. Ensure that the `client_id`, `redirect_uri`, and `scope` parameters are correctly configured and match the Azure AD app registration settings.
2. Verify the Azure AD app registration settings in the Azure portal. Ensure the `redirect_uri` matches the one used in the generated URL and that the necessary API permissions (e.g., `Mail.ReadWrite`, `User.Read.All`) are granted and admin-consented. Update the documentation in `docs/` or the CLI error messages to guide users on how to configure these settings correctly.
3. Inspect the `state` parameter in the generated URL. If it is being encoded or generated incorrectly, it could cause issues during the OAuth flow. Add debug logging in the relevant function (e.g., `GenerateAdminConsentUrl`) to log the full URL and parameters for troubleshooting.
4. Review the browser compatibility for the generated URL. The error message suggests a potential issue with the browser's handling of the OAuth flow. Test the URL in multiple browsers and document any known limitations or workarounds in the `docs/` directory, such as a new troubleshooting section.
5. Add an integration test in `src/Tests/Microsoft.Agents.A365.DevTools.Cli.Tests` to validate the admin-consent URL generation logic. Mock the Azure AD endpoints to simulate the OAuth flow and ensure the generated URL is valid and functional. Use the `MockTools` directory for mocking dependencies if needed.

---

Generated by TeamAssistant Auto-Triage powered by GitHub Models

[sellakumaran]

Thanks for the report @beyondszine .

The key question: were the permissions actually granted despite the browser error?

The "Try that again using a different browser" error appears after you click Accept — at that point consent may already be recorded in AAD. The error is on the redirect page, not on the consent step itself.

Please check:

• Open Entra portal > App registrations > find your blueprint app > API permissions
• If all permissions show "Granted for <tenant>" — consent succeeded and the browser error is cosmetic
• If permissions show "Not granted" — consent was not recorded and setup is incomplete

Alternatively:

az rest --method GET --url "https://graph.microsoft.com/v1.0/oauth2PermissionGrants?\$filter=clientId eq '<blueprint-sp-object-id>'" --query "value[].scope"

Also please let us know:

1. Which browser and OS?
2. Did the error appear immediately after clicking Accept, or did the sign-in itself fail?

[github-actions]

SLA Escalation Alert

This P3 issue has exceeded its SLA threshold.

Metric	Value
Priority	P3
SLA Threshold	120 hours
Time Since Update	134.1 hours
Current Assignees	@sellakumaran

Action: This issue is already assigned to a Tech Lead but remains unresolved.

Escalating to Engineering Manager @ajmfehr for visibility.

Tech Leads: @sellakumaran

---

Generated by AutoTriage SLA Escalation

[Jose-BV]

Hello 😃

I tested the same command: a365 setup all

Browser & OS

Browser: MS Edge - Version 149.0.4022.62 (Official build) (arm64)
OS: macOS

Execution Steps

• First, the browser displayed the sign-in prompt, which I completed successfully ✅
• Next, I received a prompt to allow permissions and clicked "Allow." The page then began loading. ⏳

• The page then displayed the following message:

Terminal Execution Logs

The CLI logs did not show any errors and confirmed that consent was successfully granted

Configuring inheritable permissions...
    Microsoft Graph: inheritable permissions already configured (kind=allAllowed on scopes and roles)
    Agent 365 Tools: inheritable permissions configured (kind=allAllowed on scopes and roles)
    Observability API: inheritable permissions configured (kind=allAllowed on scopes and roles)
    Power Platform API: inheritable permissions configured (kind=allAllowed on scopes and roles)

Configuring application permissions...
    The following application permission will be granted to the agent blueprint:
        Observability API: Agent365.Observability.OtelWrite

    Assign this application permission now? [y/N]: y
    Assigning S2S app roles...
      'Observability API': app role 'Agent365.Observability.OtelWrite' assigned.
    Application permissions granted.

Configuring delegated permissions...
    Opening browser for admin consent...
    Sign in and Accept the permission(s). If the tab shows an error after Accept, consent likely succeeded — the CLI will still detect it (timeout: 180s).
    Consent granted (All permissions).

Azure Portal - Granted Permissions

In the Azure portal, all permissions for the blueprint service principal are marked as "Granted" . When verifying the identity, all permissions were inherited correctly.

The only unexpected behavior was the "Try that again using a different browser" warning message. However, from a permissions-granting perspective, it looks like the process completed successfully.

[sellakumaran]

Thanks @Jose-BV for the thorough validation — CLI logs and the Entra portal both confirm every permission was granted and inherited correctly. The "Try that again using a different browser" message appears on the consent redirect page after Accept, by which point AAD has already recorded the grant. It's purely cosmetic, which is why we already surface:

"...If the tab shows an error after Accept, consent likely succeeded — the CLI will still detect it (timeout: 180s)."

We could likely address the redirect warning (e.g. by adding extra redirect URIs to the blueprint app), but that's not worth the added surface area for a cosmetic UI issue with no functional impact. Closing as by design / won't fix — please reopen if you ever see the CLI report success while permissions are not actually granted.