Authorization server rejects loopback redirect URIs

What it means

Native and CLI MCP clients (Claude Code, Claude Desktop, editor integrations) finish the OAuth authorization code flow by listening on a local port and using a loopback redirect URI such as http://127.0.0.1:53124/callback. The port is picked by the operating system at request time, so it is different on every login. RFC 8252 §7.3 says the authorization server MUST allow any port for loopback IP redirect URIs for exactly this reason. This finding fires when patchbay tried to register a client with loopback redirect URIs and the registration endpoint rejected them. For users the symptom is a login that hangs or errors after they click "Allow": the browser flow works, but the client can never receive the callback. The check is opt-in because it sends a real registration request. Run it with --probe-dcr-loopback. It stays silent if the server has no registration endpoint (see AUTH-005) or if the probe was inconclusive.

How to fix

Accept loopback redirect URIs in Dynamic Client Registration and at the authorization endpoint: http://127.0.0.1:PORT/callback and http://localhost:PORT/callback, with any port number. Match on scheme, host and path and ignore the port for loopback hosts only. Keep rejecting plain http:// redirect URIs for every non-loopback host. Re-run to confirm: npx -y @patchbay-nebius/agent audit <url> --probe-dcr-loopback

Spec

Background