Unable to access DCV Web Client after CDK deployment with Cognito and ALB integration

You’ve posed a great question, and it shows you’re on the right track by deploying the Amazon DCV Access Console with its companion components and layering in Amazon Cognito, an Application Load Balancer, a custom domain, and header-based authentication. I’ll summarize the likely causes of what you’re seeing (console hanging or OAuth redirect errors), then map them to your URL settings, and finally suggest a checklist to validate the flow and surface a reproducible working pattern.

What the documentation says According to AWS’s documentation for the DCV Access Console: It supports HTTP Header authentication using the authentication-header-name property, where the Auth Server uses the configured header as the user identity. : https://docs.aws.amazon.com/dcv/latest/access-console/console-authentication.html?

DCV Access Console - Authentication In a header-based flow, any intermediary (such as your ALB and Cognito) must pass the header, and the system should be configured to prevent the client (browser) from injecting or spoofing it. Header-based auth considerations : https://docs.aws.amazon.com/dcv/latest/access-console/console-authentication.html?

The ALB + Cognito configuration must ensure that the OIDC token is validated, and the expected header is correctly set and forwarded to the Authentication Server. Why your symptoms point to a routing or auth header issue

From your description: ALB and Cognito authentication completes, and Cognito issues the ID token Browser requests never reach the Auth Server or Handler (no logs appear in NGINX) NGINX successfully serves the Web Client, but the authentication flow gets stuck

This strongly suggests that the Web Client is not able to complete the handshake with the backend because: The expected header (such as x-amzn-oidc-identity) is not reaching the Auth Server ALB or NGINX is misrouting traffic, or

Redirect URIs configured in Cognito do not match what's expected by the client and backend The Auth Server is not correctly processing requests because the expected headers are missing or stripped URL configuration mapping

Key notes: redirect-uris must match exactly what's configured in your Cognito app client, including protocol, domain, and path

The Auth Server must receive the header value expected in its properties file, and this must be passed cleanly from the ALB through NGINX The Web Client must be configured with a handler base URL that is resolvable and accessible in the client’s browser context SSL certificates must cover all subdomains involved, especially if you're using a wildcard cert or SAN entries in ACM Specific things to validate ALB + Cognito rule logic

Make sure you're using the CDK AuthenticateCognitoAction on the listener, and the rule forwards successfully to NGINX after authentication If the target group isn’t reached, ALB logs should show if traffic is dropping at the rule level Header forwarding from ALB to NGINX

ALB sets x-amzn-oidc-identity, but NGINX needs to explicitly forward this to the Auth Server In your NGINX config, verify this line exists: proxy_set_header x-amzn-oidc-identity $http_x_amzn_oidc_identity;

Cognito App Client configuration Redirect URIs must exactly match what's defined in the client’s properties Use browser dev tools to inspect the full redirect chain and confirm the callback lands back on the correct path

Auth Server property file Ensure /etc/dcv-access-console-auth-server/session-manager-auth-server.properties includes: authentication-mode=header authentication-header-name=x-amzn-oidc-identity And that PAM or other modes are disabled

Handler and Web Client communication If the handler-base-url is not reachable from the client, or if CORS is misconfigured, requests will silently fail Verify the handler responds correctly to a health check or test endpoint to confirm reachability CORS, cookies, and security policies Cognito will issue authentication cookies. If these are blocked or altered in transit, your browser might appear to hang or repeatedly redirect Make sure your SSL setup and domain structure does not violate browser cross-origin policies Steps to test and debug

Enable access logs for the ALB, target groups, and NGINX Use curl or Postman to hit the Auth Server directly with the header value set to simulate the expected flow Validate that the Web Client can fetch content from the handler-base-url without redirecting or erroring Test from an incognito browser session with cookies cleared to ensure there are no session artifacts causing loops Use CloudWatch metrics for Cognito and ALB to track login, redirects, and 4xx/5xx error patterns Final thoughts

This stack is powerful but nuanced. The Cognito + ALB + header-auth pattern works well once configured correctly, but troubleshooting often comes down to: Ensuring all components agree on identity propagation Matching headers, paths, and redirect URIs precisely Validating DNS, TLS, and ACM coverage Watching for cookie and header forwarding issues at proxy boundaries

The next steps would be to review your CDK definitions, listener rule setup, NGINX config, and Auth Server properties, then walk through a clean reference deployment and map out a reproducible integration pattern.