< HTTP/1.1 561 Unauthorized

TL;DR: A 561 comes from an AWS Application Load Balancer, not your app. It means the listener’s built-in user authentication called your identity provider and got an error back. Find the request in the ALB access logs, read its error_reason, then look up the matching failure in the IdP’s logs.

What it means

561 isn’t a standard HTTP status. AWS defines it for one situation: a listener rule that authenticates users receives an error code from the identity provider (IdP). The “Unauthorized” label is misleading. It’s a vendor-specific 5xx code, not the standard 401.

So start with the listener’s authentication action and the IdP. Your application’s authorization rules probably never ran, and changing them because the browser shows “Unauthorized” won’t help. Work out which stage failed first, and you’ll know which team owns the fix.

Confirm it in access logs

Filter for elb_status_code = 561, then read actions_executed and error_reason. AWS documents authentication reason codes, including:

• AuthTokenEpRequestFailed: the token endpoint returned a non-2xx response.
• AuthUserinfoEpRequestFailed: the IdP user-info endpoint returned a non-2xx response.
• AuthInvalidGrantError: the authorization grant code from the token endpoint was invalid.

That table covers authentication errors in general, and not every one of them ends in a 561. Read the reason alongside the status recorded for the same request.

target_status_code holds the response from your application target, or - when there wasn’t one. If it’s - and elb_status_code is 561, the ALB produced the error itself; your app didn’t send that response.

Fix it

Match the ALB request’s timestamp against the IdP’s token or user-info endpoint logs. Note the endpoint, the HTTP status and a sanitized error description. Keep authorization codes, client secrets and tokens out of incident tickets.

If the IdP reports an invalid client or callback configuration, compare its application registration with the ALB authentication action. If it rejected the authorization grant, look at the login flow that produced that grant. Fix the specific rejection the IdP logged, then try a fresh login through the same listener rule.

Check the new ALB log entry, not just what the browser shows. A login that works through some other path tells you nothing about this listener’s authentication settings.

Separate endpoint errors from connectivity failures

AWS also documents authentication-related 500 errors, including when the ALB can’t reach an IdP endpoint or the endpoint takes longer than five seconds to respond. Read the status and reason together. An unreachable or slow IdP shows up as 500, not 561, and a timeout isn’t the same as the IdP rejecting the request.

Related

• 401 Unauthorized
• 500 Internal Server Error