Secure API with HttspProxy Integration behind ALB with AzureAd, Bypass will open the API for everyone

Separate Ingress Routes

Create separate ingress routes for the human-accessed API and the server-to-server API access. This will allow you to apply different authentication and authorization policies to each.

• https://myapp.test.com/api/human/* - Use Azure AD for user authentication and authorization.
• https://myapp.test.com/api/server/* - Use Client Credentials for server-to-server authentication.

Configure Azure AD for Client Credentials Flow

Set up an Azure AD application registration for your API Gateway to use the Client Credentials flow. This will allow your API Gateway to authenticate and authorize itself without the need for a user context.

• Grant the necessary permissions to this Azure AD application to access the API.
• Obtain the client ID and client secret for this application, which will be used by the API Gateway.

Implement API Gateway Authentication

Configure your API Gateway to use the Client Credentials flow when accessing the https://myapp.test.com/api/server/* endpoints. This will involve:

• Obtaining an access token from Azure AD using the client ID and client secret.
• Validating the access token and authorizing the request before forwarding it to the backend API.

Bypass Azure AD for Server-to-Server Communication

Since the API Gateway is using the Client Credentials flow, you can configure the ALB to bypass the Azure AD authentication for the https://myapp.test.com/api/server/* endpoints.

• This can be done by adding a rule in the ALB that checks the request path and bypasses Azure AD authentication if the path matches the server-side API endpoints.

Secure the Bypass Rule

To ensure that the bypass rule doesn't open up the API to everyone, you can implement additional measures:

• Restrict the bypass rule to only the specific IP ranges or network segments that the API Gateway is expected to use.
• Implement additional validation in the API Gateway to ensure that the incoming requests are from the expected and authorized sources.

I'm sorry but I do not understand your architecture, but making some guesses, what I think you need is just to use API Gateway wit Cognito as the Authorizer, integrated with Azure Entra ID Enterprise Application as the OAuth authorization mechanism. Once the user has authenticated with Azure ID they will get the bearer token, and API GW will allow to "pass through" and call the backend system which will use the same token to provide access based on the scopes. So, my first though is that you need to move all the auth logic to APIGW + Cognito... the APP should only handle the scopes in the token.

Best,