Multi-Tenancy
==================

From your case description, I understand that you have created two app clients in the user pool, which are further integrated with two different Load balancers. When the user try to log in to one application, he is also able to login into other application with any ask for login(SSO experience). 

In regard to your case, the implementation performed is called "Multi Tenancy Support". Cognito User Pool represents a single tenant, users in a user pool belong to the same directory and share the same settings like password policy, custom attributes, MFA settings, advanced security settings …etc. 

In your case, the approach of Same user pool, multiple app clients is used. Here, single user pool is used to host all users and use app client to represent tenants. This is easier to maintain, but tenants share the same settings. This approach requires additional considerations when hosted UI is used to authenticate users with native accounts; e.g. username and password. When hosted UI is in-use, a session cookie is created to maintain session for the authenticated user from cognito end, and it provides SSO experience between "application clients" in the same user pool, if SSO is not the desired behavior in your application, hosted UI shouldn’t be used with this approach to authenticate native accounts.

The cons of using same user pool, multiple app clients approach is:
- It would Require you to perform tenant match logic on client side through CustomUI to determine which app client to authenticate users against
- It would also require additional Auth logic to verify that user belongs to this tenant (since all users share one pool, it is technically possible that users authenticate against any app client)

The possible workaround in this case at the moment would be to use different user-pools for the purpose. Later, you can move ahead with the approach of using custom UI to implement the tenant match logic. 



Too Many Redirects
=====================

Known issue with Application Load Balancer (ALB) where the ALB in first response, sent 2 cookie fragments, say *-0 and *-1 and the client’s browser stored them. In the subsequent request, client is sending a request with 2 fragments, but this time the cookie size was less, so ALB only created 1 fragment, say *-0 and sent in the response.
In the next request, the client’s browser has only updated the value of *-0 cookie, but the value of *-1 is stale, and it sends both fragments instead of just 1 (which is the latest one).
The ALB then throws decrypt error, as it cannot decrypt that cookie.

I checked with internal team and understand that this is a known issue to the internal team and they are currently working on fixing this. 

As a workaround currently we cannot do much for now other than clearing the cookies everytime.