Hey folks, hoping someone here has run into this and found a fix. I've been trying to get the Amazon Q desktop client up and running with my company's SSO (Okta), and I'm hitting a really frustrating authentication loop.
I'll enter my credentials in the browser pop-up, it redirects successfully, the browser says "authenticated, you can close this window," but the desktop client just sits there spinning. A few seconds later, it pops the browser auth window open again. Rinse and repeat. I've tried the classic "clear local cache / restart" dance, but no luck.
Has anyone else battled this? I'm curious if it's specific to certain SSO providers or a broader config issue. For comparison, I've got VSCode with the AWS Toolkit extension using the same SSO flow without any hiccups, so it seems isolated to the Q client.
A couple things I've noted:
* My SSO requires MFA, which completes fine in the browser.
* The loop happens on both Mac and Windows installs for me.
* Network policies are likely fine since other AWS auth works.
Any ideas or similar experiences? Would love to get this sorted so I can dive into testing its features against some other assistants I'm using.
✌️
Oh man, that loop is the absolute worst feeling. You're just stuck in this digital purgatory. I had the exact same nightmare with a different desktop client and Okta a few months back.
For me, the culprit ended up being a mismatch in the authorized redirect URIs configured in Okta versus what the desktop client was actually expecting. It *looked* like it was redirecting fine in the browser, but the client was waiting for a specific callback that wasn't whitelisted. Your IT or identity team might need to check the app integration configuration in Okta, specifically the sign-in redirect URIs. Sometimes the desktop clients use a localhost or custom protocol URI (like `myapp://callback`) that's easy to miss.
It's super weird that VSCode works but Q doesn't, though. That points to something specific in Q's auth implementation. Have you checked if there are any specific logs generated by the Q client? Sometimes they hide away in `~/Library/Logs` on Mac or `%AppData%` on Windows and can give you the exact "redirect_uri mismatch" error that the browser window isn't showing.
That loop is maddening, especially when other tools like VSCode work fine. Since it's happening across both Mac and Windows, I'd lean toward a client-specific configuration issue rather than your local setup.
u/354's point about redirect URIs is spot on. One nuance with desktop clients is they sometimes use a different OAuth 2.0 grant flow (like Device Code or PKCE) versus what a browser extension uses. Could you ask your identity team to check the logs on the Okta side for the Amazon Q application? They might see a mismatch in the requested 'audience' or 'scopes' that the Q client sends compared to the VSCode toolkit.
Also, while you're waiting, you might try running the client with verbose logging enabled if it has that option. Sometimes the logs will show the exact callback URI it's attempting to hit.
ship early, test often