Amazon Quick Desktop (Windows) Login Loop: "Could not reach the user information service" due to local loopback port binding failure

Hello,

I am experiencing a blocking sign-in failure with the new native Amazon Quick Desktop App on Windows. When trying to authenticate, the client seamlessly redirects to Google Chrome. I am able to successfully click the orange “Allow Access” button on the official AWS SSO portal page.

However, immediately after clicking allow, the loopback redirect fails, and the application errors out with:
“Login Failed: Could not reach the user information service.”

Technical Logs & Observations:

  • Port Mismatch: The desktop app fails to securely bind to its default listener port. Chrome tries to pass the authorization callback token back to the machine over randomly assigned, shifting dynamic ports (for example, http://127.0.0... and http://127.0.0``...).
  • Connection Dropped: Because the local app client isn’t actively listening on these dynamic ports, the browser cannot complete the handshake packet.

Steps Already Attempted:

  1. Fully cleared the .aws/sso/cache/ directories.
  2. Wiped local application data within %AppData%\Amazon Quick.
  3. Tested across different default browsers (Chrome and Edge).

Is there a known patch or configuration adjustment required to lock down the specific local port the Windows desktop agent uses for OAUTH callbacks? Thank you.

Hi @sabari.infotec have you check to see if there is any specific failure in the diagnostics logs? Troubleshooting - Amazon Quick. There is also an export logs button on the login screen.

As for the “port mismatch”. Do you have another application using the port? The IdP needs to use this port for redirects. See Troubleshooting enterprise sign-in for Amazon Quick on desktop - Amazon Quick .

Another thing to keep in mind is the network requirements: Security, privacy, and architecture - Amazon Quick .

Hi @jedl

I exported the application diagnostics logs and identified what appears to be the first network failure during startup.

The desktop application starts successfully and binds its internal services on ports 8765, 8766, 8768, and 8770, indicating that the local services initialize correctly.

The first network error occurs immediately after authentication:

[LEP:warn] CONNECT failed for cognito-identity.us-east-1.amazonaws.com:443
Error: connect timeout after 8000ms

The logs also repeatedly report:

ensure_fresh: no active credential provider

and later:

Agent pre-warm failed

Additionally, my browser successfully completes the authentication flow and redirects back to the localhost callback URL with the authorization code. However, after the callback, the desktop application appears unable to establish the HTTPS connection to the Cognito endpoint, preventing it from obtaining credentials.

Could you please confirm:

  1. Is this a known issue in Quick Desktop v0.1000.2371?

  2. Is there a known timeout issue affecting connections to the us-east-1 Cognito endpoint?

  3. Are there any required outbound firewall, proxy, or SSL inspection exceptions for the Quick Desktop client? (I don`t have any antivirus sowftare)

  4. Is there additional diagnostic logging that can be enabled for the Cognito authentication client to determine why the HTTPS connection is timing out?

    How to slove this issuse I have pending project work in amazon quick so please guide me to slove this issuse.

Thank you for your assistance.

This might be a difficult one to diagnose without exposing some internal details. I would recommend opening a support case, but I will still drop some details that might unblock you.

Typically when there is a timeout there can be a few problems:

Your corporate network is blocking outbound endpoints. You can test reachability using curl:

curl -v --connect-timeout 15 --max-time 20 https://<host-in-logs>

See Security, privacy, and architecture - Amazon Quick for the appropriate endpoints.

I would test both with and without a VPN if you are using one.
I would also test download a new version of Amazon Quick desktop. The latest changes have some bug fixes for identity and network.
Lastly I would check to see if you are using an egress proxy. Egress proxies sometimes return a .pac file. This file will have your rules for allowed domains.

Hi @jedl thanks for the response. I’ve already tested:

  • curl -v https://cognito-identity.us-east-1.amazonaws.com --connect-timeout 10succeeds (HTTP 302)
  • No VPN, no proxy (netsh winhttp show proxy = Direct access)
  • Tested on Jio mobile hotspot — same error
  • Cleared all app cache (%APPDATA%\quickwork and .quickwork)
  • Running latest version 0.1000.2371

The OAuth flow completes in the browser and redirects back with the auth code, but the app fails to exchange it. Could you point me to the direct download link for the latest installer? I’d like to do a clean reinstall.

In Amazon Quick on the web you can select extensions, select the ellipsis (three dots) next to your Amazon Quick desktop extension, then select download. That always has the latest download for the binary.