Multiple Azure AD Enterprise Apps for Single Cognito User Pool

I am trying to use our Azure AD to provide auth for an internal application which is behind an ALB on AWS.

I am using a Cognito User Pool with the Azure AD configured as an identity provider.

We already have one application configured in this manner, which is accessible from anyone with an identity in Azure AD. The application I am deploying now, should only be accessible by a select few users with account admin privileges.

I have created an Enterprise Application in Azure AD Admin Center, but the issue I am having is that the application's Identifier(Entity ID) must be in the following format urn:amazon:cognito:sp:<region>_<userpool_id> and it must be globally unique.

It must be in this format because that value is used as the aud claim in the OIDC process. Since we already have an application which is uses this AD and User Pool combination, there is no way to provide the correct Entity ID because of the need for it to be globally unique across enterprise apps.

Is there some workaround for this without changing the auth config(e.g. I don't want to bypass Cognito or have ALBs targeting other ALBs)

This feels a little wrong architecturally:

AUTHORIZATION SERVER

You are using AWS Cognito in the AS role. Your apps redirect to this when beginning a login flow. Your APIs receive access tokens issued by the AS, whose scopes and claims should enable the correct API authorization.

IDENTITY PROVIDER

It is common to use a cloud IDP to manage employees, who can then use the IDP to sign into apps. This works by the app running a code flow to the AS, which in turn runs another code flow to the IDP. The app still receives tokens issued by the AS though.

AS TO IDP CONNECTIONS

There is always a single trust entry, configured in both ends of the connection:

• The AS configures an IDP connection as an authentication method
• The IDP configures an OAuth client for the AS

APPLICATIONS

The application should know nothing about the IDP. Instead, register many apps as OAuth clients in the AS. Apps also use OAuth endpoints from the AS. This is what enables you to control tokens per application.

Avoid any technology solutions that require you to register apps in the IDP. The only client entry there should be for the AS, which represents an organization, not an application.