A web application uses Amazon CloudFront with two custom origins: one origin forwards to an Amazon API Gateway HTTP API (which uses a JWT authorizer), and the other origin forwards to an Application Load Balancer (ALB). The application uses an OpenID Connect (OIDC) identity provider (IdP). A security audit finds that the API is protected by a JWT authorizer but the ALB accepts unauthenticated requests. How can the solutions architect ensure both backend origins accept requests only from authenticated users?

The correct solution is to configure the ALB to perform authentication and authorization by integrating it with the OIDC IdP. AWS ALBs can natively integrate with OIDC providers, allowing them to authenticate users before forwarding requests to backend targets. This ensures that only authenticated users can access the services behind the ALB, addressing the security audit finding directly and efficiently. Changing CloudFront to use signed URLs is incorrect because signed URLs primarily control access to CloudFront cached content or S3 origins, not directly authenticate users for an ALB origin with an OIDC IdP. Implementing a permissive signing policy would also contradict the goal of restricting access. Creating an AWS WAF web ACL to filter unauthenticated requests is incorrect because WAF is a firewall that inspects traffic based on rules, not an identity provider. It cannot perform OIDC authentication. Enabling CloudTrail logging and using a Lambda to analyze logs and block requests is an overly complex and reactive solution. It would introduce significant latency and complexity for real-time authentication and authorization, which the ALB can handle natively.