Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

LocalStack Cognito emulation has inconsistent SRP protocol support:

✅ Working:

• adminInitiateAuth with USER_SRP_AUTH flow works correctly
• Returns proper PASSWORD_VERIFIER challenge with all required parameters:
  • USER_ID_FOR_SRP
  • SALT
  • SRP_B
  • SECRET_BLOCK
  • USERNAME

❌ Failing:

• adminRespondToAuthChallenge with PASSWORD_VERIFIER challenge throws:

  InvalidParameterException: Unsupported challenge name PASSWORD_VERIFIER
  

This creates a broken authentication flow where the first step works but the second step fails, making SRP authentication impossible in LocalStack.

Expected Behavior

Both adminInitiateAuth and adminRespondToAuthChallenge should work with SRP protocol, matching AWS Cognito behavior exactly:

1. adminInitiateAuth with USER_SRP_AUTH → returns PASSWORD_VERIFIER challenge ✅
2. adminRespondToAuthChallenge with PASSWORD_VERIFIER → returns AuthenticationResult ✅

This should enable complete SRP authentication flows in LocalStack for testing purposes.

How are you starting LocalStack?

With a docker-compose file

Steps To Reproduce

Steps to reproduce the behavior.

1. Set up LocalStack with Cognito service via docker-compose

   services:
     localstack:
       image: localstack/localstack:latest
       environment:
         - SERVICES=cognito-idp
         - DEBUG=1

2. Create User Pool with SRP support

   aws --endpoint-url=http://localhost:4566 cognito-idp create-user-pool \
     --pool-name test-pool \
     --username-attributes email \
     --mfa-configuration OPTIONAL

3. Create Client with SRP auth flows

   aws --endpoint-url=http://localhost:4566 cognito-idp create-user-pool-client \
     --user-pool-id <POOL_ID> \
     --client-name test-client \
     --explicit-auth-flows "ALLOW_USER_SRP_AUTH" \
     --generate-secret

4. Create user with permanent password

   aws --endpoint-url=http://localhost:4566 cognito-idp admin-create-user \
     --user-pool-id <POOL_ID> \
     --username [email protected] \
     --user-attributes Name=email,[email protected]
   
   aws --endpoint-url=http://localhost:4566 cognito-idp admin-set-user-password \
     --user-pool-id <POOL_ID> \
     --username [email protected] \
     --password TestPass123! \
     --permanent

5. Attempt SRP authentication flow

   // Step 1: adminInitiateAuth ✅ WORKS
   const initiateResponse = await cognito.adminInitiateAuth({
     UserPoolId: 'us-east-1_xxx',
     ClientId: 'xxx',
     AuthFlow: 'USER_SRP_AUTH',
     AuthParameters: {
       USERNAME: '[email protected]',
       SRP_A: 'generated-srp-a-value'
     }
   }).promise();
   
   // Step 2: adminRespondToAuthChallenge ❌ FAILS
   const challengeResponse = await cognito.adminRespondToAuthChallenge({
     UserPoolId: 'us-east-1_xxx',
     ClientId: 'xxx',
     ChallengeName: 'PASSWORD_VERIFIER',
     ChallengeResponses: {
       USERNAME: 'user-sub',
       PASSWORD_CLAIM_SECRET_BLOCK: 'secret-block',
       TIMESTAMP: 'timestamp',
       PASSWORD_CLAIM_SIGNATURE: 'signature'
     },
     Session: initiateResponse.Session
   }).promise();

Environment

- OS: macOS 26.0
- LocalStack: 
  LocalStack version: 4.6.0
  LocalStack Docker image sha: sha256:f2985c3c9a818b52205d44e733ebe964625953763e0ff8dbab3520486c427cd5
  LocalStack build date: 2025-07-03
  LocalStack build git hash: b3b38c01f

Anything else?

Impact:

• Prevents testing SRP authentication flows in LocalStack
• Forces developers to use workarounds (fallback to non-admin methods)
• Creates inconsistency between LocalStack and AWS Cognito behavior
• Breaks authentication testing for applications using SRP protocol

Workaround:
Currently using respondToAuthChallenge instead of adminRespondToAuthChallenge for LocalStack testing, but this changes the security model and doesn't match production behavior.

AWS Cognito Behavior:
In real AWS Cognito, both adminInitiateAuth and adminRespondToAuthChallenge work perfectly with SRP protocol, making this a LocalStack-specific limitation.

Reproducible:
This issue is 100% reproducible in LocalStack environment and affects all SRP authentication flows.