Redirect URI Exact-Match Constraints in Ephemeral OAuth 2.0 Development Environments

Goal

Establish a repeatable OAuth 2.0 Authorization Code flow with PKCE (RFC 7636) across containerized development environments where the authorization server and client applications start on dynamic ports or hostnames.

Constraints and Uncertainty

The OAuth 2.0 specification (RFC 6749) requires exact-match redirect URI validation. Most providers enforce this strictly, with a documented exception only for http://localhost schemes. In ephemeral environments—such as Docker Compose stacks, Kubernetes preview namespaces, or GitHub Codespaces—the client’s redirect URI often includes an allocated port or generated hostname that cannot be known at configuration import time.

Two approaches compete: pinning fixed ports and hostnames in /etc/hosts or Docker network aliases to satisfy static registration, or scripting dynamic client registration via the authorization server’s management API at startup. The former reduces fidelity to production networking; the latter adds orchestration complexity and depends on provider-specific APIs not covered by the core specification.

Questions

1. Which approach—static port/hostname pinning or dynamic client registration—better preserves production-parity redirect URI validation behavior across Keycloak, Spring Authorization Server, and cloud-hosted providers?
2. How should the chosen strategy handle the http://localhost exception when the client runs in a container but the browser runs on the host?