Teleport Auth Service OIDC redirect_uri scheme mismatch behind TLS-terminating load balancer

Integration boundary: Teleport Auth Service ↔ external OIDC IdP (Okta, Auth0, Azure AD, Keycloak)

When Teleport is deployed behind a load balancer that terminates TLS, the Auth Service receives OIDC callbacks on its internal HTTP endpoint while the IdP expects the redirect_uri to match the public HTTPS proxy address. Teleport 15+ documents setting auth_service.public_addr to the public HTTPS URL and forwarding X-Forwarded-Proto: https, but the behavior when this header is absent remains ambiguous.

The Auth Service currently generates redirect URIs using the scheme it observes locally. If auth_service.public_addr is configured but the load balancer does not send X-Forwarded-Proto, the callback URL incorrectly uses http://, causing the IdP to reject the request with invalid_redirect_uri. This error appears only in IdP logs, not in Teleport audit logs, making diagnosis difficult.

The documentation does not clearly state whether Teleport should trust X-Forwarded-Proto by default or require explicit proxy.trusted_xff configuration, nor does it describe a fallback when the header is missing.

• Should Teleport derive the redirect_uri scheme from auth_service.public_addr unconditionally, ignoring the incoming request scheme?
• Is the intended production pattern to always require proxy.trusted_xff: true with a restricted CIDR allowlist, or is there a safe default that avoids silent failures?
• What is the recommended verification step to confirm the redirect_uri scheme matches the IdP registration before users encounter authentication failures?