How do I troubleshoot authentication issues in my Application Load Balancer?

Resolution

Misconfigurations with the identity provider (IdP) or Application Load Balancer can cause errors when you configure authentication for the Application Load Balancer. To troubleshoot authentication errors, complete the following tasks.

HTTP 400: Bad Request

redirect_mismatch

A redirect_mismatch error results in HTTP 400 when the redirect URL configuration doesn't match between your IdP and Application Load Balancer.

If you use Amazon Cognito, then set the callback URL to https://domain/oauth2/idpresponse. If you use a different IdP, then set the redirect URI to https://domain/oauth2/idpresponse.

Note: Replace domain with the domain used to access the Application Load Balancer.

HTTP 401: Unauthorized

To resolve "HTTP 401: Unauthorized" errors, complete the following tasks:

Configuration issues

Update the following configurations to match on your Application Load Balancer and IdP:

• Issuer
• Authorization endpoint
• Token endpoint
• Client ID/Client Secret

Also, set Action on unauthenticated request to either Allow, Authenticate (client reattempt), or Deny (return 401) based on your use case.

Authentication cookie issues

If your access log error code is "AuthInvalidCookie", then the authentication cookie isn't valid or is malformed. Clear browser cookies and retry authentication. Make sure that your client sends the authentication cookie during the workflow.

Invalid or missing authentication nonce

If your access log error code is "AuthInvalidAWSALBAuthNonce" or "AuthMissingAWSALBAuthNonce", then the nonce in the authentication state doesn't match a browser cookie. The cookie might differ or might be missing. Make sure that your client sends the authentication nonce cookie during the workflow.

Invalid or missing state parameters

If your access log error code is "AuthInvalidStateParam" or "AuthMissingStateParam", then the state parameter in the authentication response isn't valid or missing. Configure your IdP to return state parameters in the authentication flow. Check that the state hasn't expired.

Missing authorization code

If your access log error code is "AuthMissingCodeParam", then the authorization code parameter is missing from the IdP callback response. Configure your IdP to return authorization codes with the Authorization code grant type. Check your IdP logs for error responses such as "Service not found" or "access_denied".

Invalid ID token

If your access log error code is "AuthInvalidIdToken", then the ID token from the IdP can't be validated. Verify that the issuer in the ID token matches the issuer configured in your Application Load Balancer authentication settings. Check that the token endpoint URL, Client ID, and token signing algorithm are correct in your Application Load Balancer configuration.

Missing host header

If your access log error code is "AuthMissingHostHeader", then the authentication response from the authorization endpoint is missing a host header field. Check your IdP configuration to ensure it includes the host header in responses.

HTTP 500: Internal Server error

The load balancer must be able to communicate with the IdP token endpoint (TokenEndpoint) and the IdP user info endpoint (UserInfoEndpoint). Application Load Balancers support only IPv4 when the load balancers communicate with these endpoints.

To resolve "HTTP 500: Internal Server Error" errors, complete the following tasks:

Private domain name issues

Verify that the IdP endpoint DNS name is publicly resolvable. The authentication feature can't resolve private domain names.

Outbound rule issues

Add an outbound rule to the load balancer security group that allows traffic to the IdP endpoints over HTTPS port 443.

IdP endpoint issues

Make sure that the load balancer subnet Access Control List (ACL) allows traffic to and from the IdP endpoints:

• For egress rules, you must set the specify the Destination IP (IdP endpoints) and Destination TCP port 443 to Allow.
• For ingress rules, you must set the Source IP (IdP endpoints) and Destination TCP port range 1024-65535 to Allow.
• Configure the load balancer subnet route tables to reach the IdP endpoints:
  For internet facing load balancers, configure an Internet Gateway default route to reach the public IdP endpoints.
  For internal load balancers or balancers with a dualstack-without-public-ipv4 IP address, configure a NAT gateway or instance default route to reach public IdP endpoints.
  For all other network topology, you must have sufficient routing in place end to end to reach the IdP endpoints.

Response time issues

Make sure that the IdP token or user info endpoint respond within 5 seconds. If your access log error code is "AuthTokenEpRequestTimeout" or "AuthUserinfoEpRequestTimeout", then the load balancer generates an HTTP 500 error. Verify that your IdP endpoints are accessible and not experiencing latency or connection timeout issues. Monitor with the ELBAuthLatency metric to identify slow IdP response times.

Size limit issues

Verify that user claims don't exceed the size limit. If your access log error code is "AuthUserinfoResponseSizeExceeded", then the user claim received from the IdP might be too large. The user claim received from the IdP must be 11 KB or less in size. If the claim exceeds this limit, reduce the number of claims included in the ID token or user info response. Monitor with the ELBAuthUserClaimsSizeExceeded CloudWatch metric.

Invalid token response issues

Make sure IDP isn't providing Invalid token response. If your access log error code is "AuthInvalidTokenResponse", then the response from the token endpoint isn't valid or malformed. Verify that your IdP token endpoint returns properly formatted OAuth2 token responses.

Authorization code issues

Make sure IDP isn't providing an invalid or expired authorization code. If your access log error code is "AuthInvalidGrantError", then the authorization code from the IdP is expired or reused. Make sure that the code is exchanged for tokens before expiration and isn't reused. Verify that your IdP is configured to use the Authorization code grant type, which is the only OAuth2 grant type supported by Application Load Balancers.

Invalid user info response issues

If your access log error code is "AuthInvalidUserinfoResponse", then the response from the user info endpoint isn't valid or malformed. It might contain NULL or invalid query arguments. Verify that your IdP user info endpoint returns properly formatted responses according to the OpenID Connect specification.

HTTP 561: Unauthorized error from IdP endpoint

HTTP 561 errors occur when the Application Load Balancer receives an error response from the IdP endpoints. Monitor this error with the ELBAuthError CloudWatch metric.

To resolve HTTP 561 errors, complete the following tasks:

Verify IdP endpoint configuration

• Check that the token endpoint URL and user info endpoint URL are correct in your Application Load Balancer listener configuration.
• Make sure that the Client ID and Client Secret are valid and match your IdP configuration.
• Verify that the Client Secret hasn't expired or been rotated without updating your load balancer configuration.

Check IdP endpoint availability and response

If your access log error code is "AuthTokenEpRequestFailed" or "AuthUserinfoEpRequestFailed", then verify that your IdP token endpoint and user info endpoint are accessible. They must return 2XX success responses. Review your IdP logs for error messages such as "invalid_client", "invalid_request", rate limiting issues, or service disruptions.

Verify token and scope configuration

Make sure that the authorization code hasn't expired. Check that you've granted the required scopes, including openid, email, or profile.

Verify that the IdP endpoint certificate matches the configured hostname

If your access log error code is "AuthTokenEpRequestFailed" or "AuthUserinfoEpRequestFailed", then the certificate served by the IdP endpoint doesn't include the configured hostname. The Application Load Balancer validates that the hostname in the configured IdP endpoint URL matches the certificate's Subject Alternative Name (SAN) or Common Name (CN). If the certificate served by the IdP endpoint doesn't include the configured hostname, the load balancer rejects the connection. Verify that your IdP endpoint certificate includes the configured hostname in its SAN or CN. Or, update your Application Load Balancer configuration to use a hostname that matches your existing certificate.

Monitor authentication with CloudWatch

You can monitor authentication performance and errors with the following Amazon CloudWatch metrics:

• ELBAuthSuccess: Tracks successful authentication actions
• ELBAuthFailure: Tracks authentication failures due to invalid credentials or denied access (HTTP 401 errors)
• ELBAuthError: Tracks authentication errors due to misconfiguration or IdP connection issues (HTTP 500/561 errors)
• ELBAuthUserClaimsSizeExceeded: Tracks instances where user claims exceed 11 KB
• ELBAuthLatency: Measures IdP response time in milliseconds
• ELBAuthRefreshTokenSuccess: Tracks successful token refresh operations

Turn on access logs to capture the error_reason field, which contains specific error codes for detailed troubleshooting. For more information, see Access logs for your Application Load Balancer.

Additional HTTP error codes

To troubleshoot additional HTTP error codes that Application Load Balancers generate, see The load balancer generates an HTTP error.

Related information

Simplify login with Application Load Balancer built-in authentication

Authenticate users using an Application Load Balancer

Application-specific settings with app clients