bug: Cognito existing-user login returns an invalid authorization code on 2026.08.2 #53
edmonshi
started this conversation in
Bugs (AWS)
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Current behavior
On
localstack/localstack:2026.08.2container, opening the Cognito login page sets anls_cognito_tokencookie containingclient_id,code, andlocation, even before password authentication. The cookie has nousername.The hosted UI's existing-user action redirects to the cookie's
location. Exchanging that callback's code at/_aws/cognito-idp/oauth2/tokenreturns HTTP 400 with:Fresh username/password login succeeds and its authorization code exchanges for tokens (HTTP 200). However, reopening the login page with that authenticated cookie replaces it with another cookie lacking
username, and exchanging the new callback code fails again.Expected behavior
An anonymous visitor should be shown the credentials form. After a successful login, if a remembered session is offered, continuing as that user should return a valid authorization code for the current request that can be exchanged for tokens.
Steps to reproduce
This reproduces on a clean stock container, a new pool/client/user, no application source, no startup patches, and no shared data volume. The script uses the image's installed boto3 and Python standard library. All requests stay inside the container.
compose.yamlandrepro.pyin an empty directory.LOCALSTACK_AUTH_TOKENin your shell to a token with Cognito access.The test covers two flows: direct
/loginwith only the required OAuth parameters (no PKCE), and/oauth2/authorizewith state, scopes, and PKCE. For password login it includes bothInitiateAuthand the form POST used by the hosted UI.This is an HTTP reproduction, not browser automation. It reads the cookie callback used by the hosted UI's
existingProceed()function. Its assertions expect the observed failure, so exit status 0 means the bug reproduced.compose.yaml
repro.py (disposable test credentials only)
Observed results
Both flows produced the same results:
Environment
localstack/localstack:2026.08.2.sha256:03e20255bd27eb6c5eee1e55d64ad97bbec46505981c92313481096e90f24fde.us-east-1.2026.04.0and2026.08.0.Investigation / related history
The observed cookie replacement appears to be the cause: opening the page supplies a new callback code that the token endpoint rejects, while the code from password authentication works. This happens without PKCE as well, so PKCE is not required to trigger it.
I searched existing open/closed issues and Discussions and did not find an exact match. Related history: #5310 introduced cookie-based re-login, and the reporter confirmed that behavior worked. That suggests a possible regression, but I have not identified the introducing version.
Is this a known issue, or is additional configuration required for the remembered-user flow? Happy to provide more info.
All reactions