Hi all following AWS’s official guide (Set up enterprise sign-in with Microsoft Entra ID for Amazon Quick on desktop) step by step, but the desktop app
never actually reaches Microsoft’s login page. Looking for anyone who’s hit this or can point to what we’re missing.
What we’ve completed, per the docs:
Step 1 Entra ID app registration:
- Public client, single-tenant, redirect URI http://localhost:18080 under “Mobile and desktop applications”
- API permissions granted (delegated, admin consent granted): openid, email, profile, offline_access
- email optional claim added to the ID token
- “Allow public client flows” = Yes
Step 2 Extension access (Amazon Quick admin console): - Issuer URL: https://login.microsoftonline.com/<TENANT_ID>/v2.0 (confirmed /v2.0 suffix present)
- Authorization/Token endpoints and JWKS URI entered per the standard Entra v2.0 pattern
- Client ID matches the app registration exactly
- Double- and triple-checked all values before submitting (since this can’t be edited after creation)
Step 3 Extension created:
- Extensions page shows the extension as Active
- We even deleted and fully recreated the extension access + extension from scratch to rule out a corrupted config same result
Step 4 Download & test:
- Downloaded the Windows desktop app directly from the Extensions page
- On the sign-in screen, clicking Continue with SSO does not redirect to login.microsoftonline.com at all
- Instead it shows Amazon Quick’s own native username/password
Additional context:
- Per the “How enterprise sign-in works” doc, this native screen is expected only when there’s no active Amazon Quick web session yet, and should let you
sign in to Quick once before the app completes SSO through the IdP. We understand this as a one-time bootstrap step but we can’t get authentication to
succeed past this native screen at all (getting AUTHENTICATION_FAILED / HTTP 400 on that screen), so we never reach the point of finding out if the Entra ID
redirect would even work afterward. - We’ve also confirmed (via binary inspection of the downloaded exe) that the desktop client is a generic, non-tenant-specific build so this isn’t
something wrong with a corrupted local install. - AWS Support case is open on my account, but progress has been slow hoping the community has hit this specific “never redirects to IdP” symptom
before.
Question: Given the config above checks out against the documented steps, what typically causes the desktop app to fail to redirect to the IdP at all (Stage
1 never resolving), rather than failing later with a token/claims error? Is there a way to force/debug this handoff, or logs we should be pulling on the
Quick side rather than the Entra side?
Thanks in advance.