Multiple SSO app client connections in same user pool

Creating a new user pool with only the required attributes for each app client is not the recommended approach for your situation. This would lead to a fragmented user management system and potentially cause issues with user experience and data consistency across your applications.

Instead, consider the following alternatives:

1. Optimize existing attributes: Review your current 40 custom attributes and see if any can be consolidated or removed. This could free up space for the new attributes you need.

2. Use attribute mapping: If some of the attributes you need are coming from external identity providers (IdPs), you can use attribute mapping to map IdP attributes to your user pool attributes. This can help reduce the number of custom attributes you need to define in your user pool.

3. Implement app-client multi-tenancy: This approach allows you to use a single user pool for multiple app clients while maintaining tenant-specific configurations. Each app client can have its own set of attributes and configurations within the same user pool. This preserves user profiles across different applications and allows for more efficient management.

4. Use custom scopes: Instead of creating new attributes, you can use custom scopes to control access to specific resources or features for different app clients. This can help reduce the need for additional attributes.

5. Leverage external storage: For attributes that don't need to be used in authentication or authorization decisions, consider storing them in an external database and linking them to the user's Cognito ID. This can help you overcome the attribute limit while still maintaining the necessary information.

If after implementing these strategies you still find that you need more than 50 attributes, then you may need to consider creating a new user pool. However, instead of creating a separate pool for each app client, you could create a new pool that groups related app clients together based on their attribute requirements. This would still allow for some user profile sharing between related applications while giving you more flexibility with attributes.

Remember, when working with multiple user pools, you'll need to implement additional logic in your applications to handle user authentication and profile management across pools. This can increase complexity and potentially impact user experience, so it should be considered as a last resort.

Sources
App-client multi-tenancy best practices - Amazon Cognito
SaaS authentication: Identity management with Amazon Cognito user pools | AWS Security Blog
Mapping IdP attributes to profiles and tokens - Amazon Cognito
Custom-attribute multi-tenancy best practices - Amazon Cognito

You can’t remove custom attributes once they’re added to a user pool.

You’re stuck with 50 total custom attributes, period.

And no, Cognito doesn’t support dynamic mapping of IdP attributes at runtime. The mapping is fixed per IdP and user pool config — can’t switch it on the fly.

So yeah, creating a new user pool with only the attributes you really need is the only clean way forward if you're out of room. Just keep in mind that users won't be shared across pools, so you’d have to handle that logic if you split clients.

What worked for us was keeping Cognito minimal and storing anything extra in DynamoDB keyed by the Cognito