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

Direct answer

Yes: when auth_service.public_addr is set to an https:// address, the OIDC callback URL should be built from that configured public address, not from the scheme of the incoming request. The http:// redirect_uri you are seeing is the fallback behavior: the Auth Service terminates plain HTTP internally and, with no trusted X-Forwarded-Proto header, uses the local request scheme when constructing the redirect_uri. That is the defect to eliminate, not to accommodate.

Likely explanation vs. confirmed facts

Confirmed: Okta, Auth0, Azure AD, and Keycloak all do exact string matching of redirect_uri against registered values. An http/https difference alone triggers invalid_redirect_uri, and the rejection is logged only on the IdP side — Teleport audit logs will not show it.

Likely, but verify against your version: the exact configuration key names (such as a trusted_xff-style setting) and the default header‑trust behavior vary across Teleport releases. The Teleport 15+ behavior described in your question could not be confirmed against current documentation, so check the configuration reference for your deployed version before changing keys.

Recommended production pattern

1. Set auth_service.public_addr to the full public https:// address.
2. Configure the load balancer to set X-Forwarded-Proto: https on every forwarded request.
3. Restrict Auth Service ingress so only the load balancer can reach it (security group, firewall, or CIDR allowlist). Never honor forwarded headers on an Auth Service reachable by untrusted clients — header spoofing can poison redirects and logs.
4. If the load balancer cannot send the header, terminate TLS at the Teleport proxy layer itself instead of relying on scheme inference.

There is no safe default that silently tolerates a missing header; the safe posture is scheme‑correct public_addr plus a network topology where only the LB can inject forwarding headers.

Verification before users hit the failure

1. Initiate an SSO login and inspect the authorize request in browser dev tools (or the IdP system log). Confirm the redirect_uri parameter is https:// and matches the registered value character‑for‑character.
2. From the load balancer host, send test requests with and without X-Forwarded-Proto and confirm the generated callback URL is stable and https in both cases.
3. Confirm the Auth Service is not directly reachable from untrusted networks, so the header cannot be injected by end users.

One missing detail that would change this recommendation: your exact Teleport version, since the relevant key names and defaults are version‑sensitive.