Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Building off of #10007 which was closed due to lack of activity, the behaviour described within that ticket still exists in version 3.8.0 of localstack-pro using Docker.

The issue presents in two different ways. As described in the original issue, the IDP_PROVIDERS const which is set up on the hosted UI does not fill in any details, leading to the following definition and subsequent breaking usage:

const IDP_PROVIDERS = [{"name": "demo-client-1", "type": "OIDC", "details": {}}];
const CALLBACK_URL = 'https://localhost:4566/_aws/cognito-idp/oauth2/idpresponse';
...
function idpLogin(idpName) {
  const idp = IDP_PROVIDERS.filter(idp => idp.name === idpName)[0];
  const details = idp.details || {};
  const url = `${details.authorize_url}?response_type=code&redirect_uri=${CALLBACK_URL}&` +
      `client_id=${details.client_id}&scope=${details.authorize_scopes}`;
  document.location.href = url;
}
...
<button class="btn btn-primary signin" onclick="idpLogin('demo-client-1')">demo-client-1 (OIDC)</button>

This does have a workaround by manually overriding IDP_PROVIDERS[0].details in the developer console, but there is a second issue. The CALLBACK_URL as described above, when returned back from the IdP, does not perform any actions.

When used as such, the IdP returns the following URL that, while it returns a 200, performs no actions.

https://localhost:4566/_aws/cognito-idp/oauth2/idpresponse?session_state=08b2054f-9ca9-4583-8bb4-7d852b3a7130&iss=http%3A%2F%2Flocalhost%3A8080%2Frealms%2Fmaster&code=1abf2966-82c4-4628-b458-c666b6ac7b88.08b2054f-9ca9-4583-8bb4-7d852b3a7130.0c8e6c47-737b-4303-b875-0ca9df2f9add

Expected Behavior

When using an IdP, the login portal should be able to source the details to pass onto the IdP without manual intervention.

When receiving a response from an IdP, the response portal should be able to validate that identity and pass the user back to the application that they originally requested authentication for.

How are you starting LocalStack?

With a docker-compose file

Steps To Reproduce

How are you starting localstack (e.g., bin/localstack command, arguments, or docker-compose.yml)

docker run localstack/localstack-pro:3.3.0

Client commands (e.g., AWS SDK code snippet, or sequence of "awslocal" commands)

• Create identity provider that requires OIDC (done using keycloak)
• Create a basic Cognito user pool (done using Terraform)
• Create Cognito client and register the IdP as supported
• Create a minimal site that requires OIDC authentication against Cognito client
• Attempt to log into the site and use the secondary IdP
• To use the initial workaround, run aws --endpoint http://localhost:4566 cognito-idp describe-identity-provider --user-pool-id <pool_id> --provider-name <idp_provider_name> and copy the provider details block
• Visit the login screens again and run the following in the console before clicking on the login using idp link:

IDP_PROVIDERS[0].details = {
  "oidc_issuer": "http://host.docker.internal:8080/realms/master",
  "token_url": "http://host.docker.internal:8080/realms/master/protocol/openid-connect/token",
  "attributes_request_method": "GET",
  "authorize_url": "http://localhost:8080/realms/master/protocol/openid-connect/auth",
  "attributes_url": "http://host.docker.internal:8080/realms/master/protocol/openid-connect/userInfo",
  "client_id": "demo-client-1",
  "jwks_uri": "http://host.docker.internal:8080/realms/master/protocol/openid-connect/certs",
  "authorize_scopes": "email profile openid",
  "client_secret": "<client_secret>"
};

I'll try to get a minimal project created over the weekend that can be used to reproduce the issue easily.

Environment

- OS: MacOS 23.6.0
- LocalStack:
  LocalStack version: 3.8.0
  LocalStack Docker image sha: 71b22b9d2fc4bd9edadfb7502887f6507be0cccc4f76fb1a1972672845554b34
  LocalStack build date: 2024-10-03
  LocalStack build git hash: 1df3c1c2

Anything else?

No response