HTTP D. Hardt Internet-Draft Hellō Intended status: Standards Track S. Goto Expires: 9 July 2026 Google 5 January 2026 HTTP Redirect Headers draft-hardt-httpbis-redirect-headers-00 Abstract This document defines HTTP headers that enable secure parameter passing and mutual authentication during browser redirects. The Redirect-Query header carries parameters in browser-controlled headers instead of URLs, preventing leakage through browser history, Referer headers, server logs, and analytics systems. The Redirect- Origin header provides browser-verified origin authentication that cannot be spoofed or stripped, enabling reliable mutual authentication between parties. The optional Redirect-Path header allows servers to request path-specific origin verification. Together, these headers address critical security and privacy concerns in authentication and authorization protocols such as OAuth 2.0, OpenID Connect, and SAML. Discussion Venues _Note: This section is to be removed before publishing as an RFC._ Source for this draft and an issue tracker can be found at https://github.com/dickhardt/redirect-headers (https://github.com/dickhardt/redirect-headers). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Hardt & Goto Expires 9 July 2026 [Page 1] Internet-Draft Redirect Headers January 2026 This Internet-Draft will expire on 9 July 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Redirect Headers . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Redirect-Query . . . . . . . . . . . . . . . . . . . . . 4 2.2. Redirect-Origin . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Example 1: Origin-only verification (without Redirect-Path) . . . . . . . . . . . . . . . . . . . 5 2.2.2. Example 2: Origin+path verification (with Redirect-Path) . . . . . . . . . . . . . . . . . . . 6 2.3. Redirect-Path . . . . . . . . . . . . . . . . . . . . . . 6 3. Feature Discovery . . . . . . . . . . . . . . . . . . . . . . 7 4. OAuth Incremental Deployment . . . . . . . . . . . . . . . . 7 4.1. How It Works . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Adoption Path . . . . . . . . . . . . . . . . . . . . . . 8 5. OAuth Redirect Security Threats . . . . . . . . . . . . . . . 8 5.1. Authorization Code Theft from URL Query Strings . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6.1. Header Confidentiality . . . . . . . . . . . . . . . . . 10 6.2. Browser Implementation Requirements . . . . . . . . . . . 10 6.3. Origin Verification Limits . . . . . . . . . . . . . . . 11 6.4. Browser Trust Model . . . . . . . . . . . . . . . . . . . 11 6.5. Transition Period Risks . . . . . . . . . . . . . . . . . 11 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 7.1. URL History and Referer Leakage . . . . . . . . . . . . . 12 7.2. Network Observer Privacy . . . . . . . . . . . . . . . . 12 7.3. Redirect-Origin Privacy Implications . . . . . . . . . . 12 7.4. User Control and Transparency . . . . . . . . . . . . . . 13 7.5. Server Logging Practices . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8.1. Redirect-Query Header Field . . . . . . . . . . . . . . . 13 8.2. Redirect-Origin Header Field . . . . . . . . . . . . . . 14 Hardt & Goto Expires 9 July 2026 [Page 2] Internet-Draft Redirect Headers January 2026 8.3. Redirect-Path Header Field . . . . . . . . . . . . . . . 14 8.4. Redirect-Supported Header Field . . . . . . . . . . . . . 14 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. OAuth Example: Before and After . . . . . . . . . . 16 A.1. Without Redirect Headers (current OAuth) . . . . . . . . 16 A.2. With Redirect Headers . . . . . . . . . . . . . . . . . . 17 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction Authentication and authorization protocols (OAuth [RFC6749], OpenID Connect [OIDC], SAML [SAML]) use browser redirects to navigate users between applications and authorization servers. These redirects must carry protocol parameters, which historically appear in URLs or POSTed forms. This document addresses two distinct problems in redirect-based protocols: 1. *Parameter Leakage*: URL parameters leak sensitive data (authorization codes, tokens, session identifiers) through browser history, Referer headers, server logs, analytics systems, and JavaScript access. POST-based redirects expose parameters in DOM form fields. Both mechanisms make sensitive data visible to unintended parties. 2. *Origin Verification*: Current mechanisms for verifying the origin of redirects are unreliable. The Referer header may be stripped, rewritten, or removed by privacy tools and enterprise proxies, preventing reliable mutual authentication between parties. This document defines two HTTP headers that address these problems: * *Redirect-Query* - Carries parameters in a browser-controlled header instead of URLs, preventing leakage while always being paired with origin verification * *Redirect-Origin* - Provides browser-verified origin authentication that cannot be spoofed by scripts or manipulated by intermediaries A third header, *Redirect-Path*, allows servers to request path- specific origin verification when finer-grained validation is needed. Hardt & Goto Expires 9 July 2026 [Page 3] Internet-Draft Redirect Headers January 2026 *Note on independent use*: While origin verification without parameter passing is theoretically possible (server sends Redirect- Path, browser responds with Redirect-Origin), no specific use cases have been identified for this configuration. *Incremental Deployment:* A key feature of this specification is that deployment does not require coordination between parties. Each party (client application, browser, authorization server) can independently add support for Redirect Headers. Full functionality emerges naturally when all three parties support the mechanism, but partial deployment gracefully degrades to existing URL-based behavior. This allows for organic adoption without requiring synchronized upgrades across the ecosystem. 2. Redirect Headers Three headers work together during top-level 303 redirects to provide secure parameter passing and mutual authentication: *Redirect-Query* carries parameters from servers (client applications or authorization servers) to the browser, which then forwards them to the next party. This keeps sensitive data out of URLs while maintaining the redirect flow. *Redirect-Origin* provides browser-verified origin authentication. The browser sets this header when forwarding redirect parameters, allowing the receiving party to verify where the redirect originated. This cannot be spoofed by scripts or stripped by intermediaries. *Redirect-Path* (optional) allows servers to request path-specific origin verification for finer-grained validation within an origin. *Browser behavior:* Only processes these headers during top-level redirects. Ignores them for normal requests or embedded resources. 2.1. Redirect-Query The Redirect-Query header carries redirect parameters using URL query string encoding. It is set by servers (either the client application or authorization server) in redirect responses. Redirect-Query: "code=SplxlOBe&state=123" *Properties:* * Set by server in HTTP 303 redirect response * Replaces URL query parameters * Parsed using standard URL query string parsing Hardt & Goto Expires 9 July 2026 [Page 4] Internet-Draft Redirect Headers January 2026 * Prevents exposure via browser history, Referer, logs, and analytics * When present, browser MUST include Redirect-Origin in the subsequent request 2.2. Redirect-Origin The Redirect-Origin header provides browser-verified origin authentication. It is set ONLY by the browser and contains the origin (and optionally path) of the page from which the redirect originated. *Format:* Always ends with / *Properties:* * Set ONLY by the browser (cannot be spoofed by scripts or intermediaries) * Enables receiving party to verify the origin of the redirect * Provides mutual authentication between parties * Always ends with / for consistent parsing * May include validated path when Redirect-Path is used *Browser behavior:* The browser sets Redirect-Origin when either Redirect-Query or Redirect-Path is present in the redirect response. 2.2.1. Example 1: Origin-only verification (without Redirect-Path) *Current page:* https://app.example/some/page *Server sends redirect:* HTTP/1.1 303 See Other Location: https://as.example/authorize Redirect-Query: "client_id=abc&state=123" *Browser forwards to AS:* GET /authorize Host: as.example Redirect-Origin: "https://app.example/" Redirect-Query: "client_id=abc&state=123" The Redirect-Origin is set to the origin plus /, without any path component. Hardt & Goto Expires 9 July 2026 [Page 5] Internet-Draft Redirect Headers January 2026 2.2.2. Example 2: Origin+path verification (with Redirect-Path) *Current page:* https://app.example/mobile/dashboard *Server sends redirect:* HTTP/1.1 303 See Other Location: https://as.example/authorize Redirect-Query: "client_id=abc&state=123" Redirect-Path: "/mobile/" *Browser validates path claim:* - Redirect-Path claim: /mobile/ - Current page path: /mobile/dashboard - Validation: Does /mobile/ dashboard start with /mobile/? ✓ YES *Browser forwards to AS:* GET /authorize Host: as.example Redirect-Origin: "https://app.example/mobile/" Redirect-Query: "client_id=abc&state=123" The Redirect-Origin includes the validated path /mobile/ because the browser confirmed the current page is within that path. *If path validation fails:* If the current page was https://app.example/desktop/page and the server claimed Redirect-Path: "/mobile/", the browser would reject the path claim and send only the origin: Redirect-Origin: "https://app.example/" 2.3. Redirect-Path The Redirect-Path header allows a server to request path-specific origin verification. It is set by the server in the redirect response as a claim about the current page's path. The browser validates this claim and, if valid, includes the path in Redirect- Origin. *Format:* Must start with / Redirect-Path: "/app1" *Server behavior:* Hardt & Goto Expires 9 July 2026 [Page 6] Internet-Draft Redirect Headers January 2026 The server includes Redirect-Path in the redirect response when it wants the receiving party to know not just the origin, but also a specific path within that origin. *Browser validation:* 1. Server sends: Redirect-Path: "/api" 2. Browser checks: Does the current page path start with /api? 3. If valid: Include path in Redirect-Origin: "https://example.com/ api/" 4. If invalid: Ignore the path claim, use origin only: Redirect- Origin: "https://example.com/" This mechanism prevents path manipulation attacks where an attacker might try to redirect from an unexpected path within the same origin. The server cannot lie about its path because the browser enforces validation. 3. Feature Discovery Some protocols may wish to discover browser support for Redirect Headers using Client Hints [RFC8942]. *Server advertises support:* Accept-CH: Redirect-Supported *Browser responds with capability:* Redirect-Supported: ?1 *Note:* Feature discovery is optional and not required for OAuth flows. The incremental deployment model works without explicit discovery - authorization servers detect support by receiving Redirect-Query headers in requests. 4. OAuth Incremental Deployment Redirect Headers is designed for *incremental adoption* - each party (client, browser, authorization server) can independently add support, with functionality emerging when all parties support it. 4.1. How It Works *Clients* can start sending parameters in both locations: * URL query string (for backward compatibility) * Redirect-Query header (signaling support) Hardt & Goto Expires 9 July 2026 [Page 7] Internet-Draft Redirect Headers January 2026 *Browsers* forward Redirect- headers when present: * No special detection needed * Simply forward the headers during redirects *Authorization Servers* detect support and respond accordingly: * If request includes Redirect-Query → AS knows both client and browser support it * AS can then send response using *only* Redirect-Query header (no URL parameters) 4.2. Adoption Path Each party adds support independently, in any order: *Clients* add support by sending parameters in both the URL query string and the Redirect-Query header, and by looking for responses in the header while falling back to URL parameters. *Browsers* add support by forwarding Redirect-* headers when present during redirects. No configuration is needed. *Authorization Servers* add support by detecting when Redirect-Query is received (confirming that both the client and browser support it), then sending responses using only the Redirect-Query header and omitting URL parameters. *Result:* Once all three parties support it, the authorization code is sent in the header rather than the URL. *No coordination required* - each party adds support independently, and the system naturally converges to the secure behavior once all three support it. The client can immediately start sending both, browsers simply forward headers, and authorization servers detect support from incoming requests. 5. OAuth Redirect Security Threats *Scope:* Redirect Headers specifically addresses OAuth and OIDC web- based redirect flows between websites where sensitive parameters are passed via URL query strings. This proposal does NOT address form_post mechanisms where data appears in the DOM, as that attack vector requires different mitigations. Hardt & Goto Expires 9 July 2026 [Page 8] Internet-Draft Redirect Headers January 2026 5.1. Authorization Code Theft from URL Query Strings The primary security weakness is in the *authorization server's response* containing the authorization code in the URL query string. When an AS redirects back to the client with ?code=...&state=..., the authorization code is exposed through multiple vectors: *Known attack vectors:* 1. *Browser history leakage* - Authorization codes stored in browser history can be retrieved by attackers with device access * Reference: OAuth 2.0 Security Best Current Practice [RFC9700] 2. *Server log exposure* - Authorization codes visible in web server access logs, proxy logs, and load balancer logs * Codes can be extracted in real-time or from archived logs 3. *Referer header leakage* - When the callback page loads third- party resources (images, scripts, analytics), the authorization code leaks via the Referer header * Reference: OAuth 2.0 authentication vulnerabilities [PORTSWIGGER-OAUTH] 4. *Browser-swapping attacks* - Attackers exploit scenarios where authorization codes leak through shared URLs or when users switch browsers during the flow * Discussion: OAuth-WG Browser-Swapping thread 5. *URL sharing* - Users may inadvertently share URLs containing authorization codes after errors or confusion 6. *Analytics and crash reporting* - Authorization codes captured by analytics systems, error tracking, and monitoring tools *What Redirect Headers mitigates:* By moving the authorization code from the URL query string to the Redirect-Query header, *all of these attack vectors are eliminated*. The authorization code never appears in: * URLs (no browser history exposure) * Referer headers (no leakage to third parties) * Server logs (when servers are configured to not log sensitive headers) Hardt & Goto Expires 9 July 2026 [Page 9] Internet-Draft Redirect Headers January 2026 * User-visible locations (no accidental sharing) *Important clarification:* The security concern is specifically the *authorization server's response* with the authorization code. The *client's authorization request* to the AS (containing client_id, redirect_uri, state) does not have known security concerns from being in the URL, as these parameters are not sensitive credentials. However, moving them to headers provides consistency and reduces URL clutter. 6. Security Considerations 6.1. Header Confidentiality Redirect-Query carries sensitive parameters (authorization codes, tokens, session identifiers) that MUST be protected with the same care as credentials. Servers MUST: * Configure logging systems to exclude or redact Redirect-Query header values * Treat Redirect-Query with the same confidentiality as Authorization headers * Use TLS for all redirects carrying Redirect-Query to prevent network observation Network intermediaries (proxies, load balancers, CDNs) can observe header values in transit. Deployment environments with untrusted intermediaries require additional protection beyond this specification. 6.2. Browser Implementation Requirements Browsers MUST enforce strict isolation of Redirect headers: * JavaScript MUST NOT be able to read or set Redirect-* headers via any API * Browser extensions MUST NOT have access to Redirect-* headers * Only the browser's redirect handling mechanism can create or consume these headers * Headers MUST only be processed during top-level navigation redirects, never for subresource requests Failure to enforce these restrictions would allow malicious scripts to forge origin claims or steal sensitive parameters. Hardt & Goto Expires 9 July 2026 [Page 10] Internet-Draft Redirect Headers January 2026 6.3. Origin Verification Limits Redirect-Origin provides browser-mediated mutual authentication but has limitations: * It verifies the browser's understanding of origin, not the server's identity * It does not authenticate the user or establish a secure channel * It supplements but does NOT replace redirect_uri validation and registration * Servers MUST continue to validate redirect_uri against registered values Redirect-Path provides additional validation within an origin but cannot prevent attacks where the attacker controls a legitimate path within the same origin. 6.4. Browser Trust Model This specification assumes an honest browser implementation. It cannot protect against: * Compromised or malicious browsers * Browser bugs that fail to enforce header restrictions * Browser extensions with elevated privileges * Debugging tools that modify headers Servers should monitor for anomalous behavior (e.g., Redirect-Origin values that don't match expected patterns) as potential indicators of browser compromise or implementation bugs. 6.5. Transition Period Risks During incremental deployment, clients may send parameters in both URL and headers for backward compatibility. This dual-sending pattern preserves URL leakage risks until: * All parties (client, browser, server) support Redirect Headers * Clients stop including parameters in URLs Servers SHOULD detect Redirect-Query presence and warn or reject requests that also include sensitive parameters in URLs, to encourage migration away from URL-based parameters. 7. Privacy Considerations Hardt & Goto Expires 9 July 2026 [Page 11] Internet-Draft Redirect Headers January 2026 7.1. URL History and Referer Leakage When parameters remain in URLs (as during transition or with non- supporting implementations), sensitive data persists in browser history and may leak via Referer headers. Implementers should consider: * Browser history is persistent storage that may be accessed by malware, forensic tools, or unauthorized users with device access * Referer headers are sent automatically to third-party resources, potentially leaking parameters to analytics providers, CDNs, or advertisers * The transition to headers does not eliminate these risks until all parties stop sending parameters in URLs This specification does not eliminate all tracking vectors - cookies, browser fingerprinting, and other mechanisms remain unaffected. 7.2. Network Observer Privacy Network intermediaries can still observe Redirect-* headers in transit, just as they can observe URL parameters today. This specification does not enhance privacy against network-level observers (ISPs, proxies, corporate firewalls). TLS remains essential for protecting parameters from network observation. In some cases, moving parameters to headers may slightly improve privacy: unlike URL paths (which may be visible in TLS SNI or DNS queries), HTTP headers are encrypted by TLS and not visible to passive network observers. 7.3. Redirect-Origin Privacy Implications Redirect-Origin explicitly reveals the origin (and optionally path) of the redirecting page. Implementers should consider: * This is similar to the Referer header but more reliable and always present when Redirect-Query is used * It enables the receiving party to know definitively where the redirect originated * Unlike Referer (which users/tools can strip for privacy), Redirect-Origin cannot be disabled by the user when Redirect-Query is present * This trade-off prioritizes security (mutual authentication) over origin hiding Hardt & Goto Expires 9 July 2026 [Page 12] Internet-Draft Redirect Headers January 2026 Protocols using Redirect Headers should only be deployed where mutual knowledge of party identities is acceptable and expected (as in OAuth, where the AS and client already know each other). 7.4. User Control and Transparency Users have limited control over Redirect Headers: * Users cannot inspect or modify Redirect-* headers (unlike URL parameters which are visible) * Users cannot selectively disable Redirect-Origin without breaking functionality * Browser developer tools may or may not expose these headers depending on implementation Browser implementations SHOULD provide visibility into Redirect Headers in developer tools for transparency, while maintaining the security restriction that JavaScript cannot access them. 7.5. Server Logging Practices While Redirect Headers remove parameters from URLs (reducing accidental logging via URL-based logs), servers must implement appropriate logging controls: * Configure web servers and load balancers to exclude Redirect-Query from access logs * Ensure application logging redacts sensitive header values * Be aware that default logging configurations may capture all headers The shift to headers does not automatically prevent logging - it requires conscious configuration changes. 8. IANA Considerations This document registers four new HTTP header fields in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" defined in [RFC9110]. 8.1. Redirect-Query Header Field Header field name: Redirect-Query Applicable protocol: http Status: standard Author/Change controller: IETF Hardt & Goto Expires 9 July 2026 [Page 13] Internet-Draft Redirect Headers January 2026 Specification document(s): [this document] 8.2. Redirect-Origin Header Field Header field name: Redirect-Origin Applicable protocol: http Status: standard Author/Change controller: IETF Specification document(s): [this document] 8.3. Redirect-Path Header Field Header field name: Redirect-Path Applicable protocol: http Status: standard Author/Change controller: IETF Specification document(s): [this document] 8.4. Redirect-Supported Header Field Header field name: Redirect-Supported Applicable protocol: http Status: standard Author/Change controller: IETF Specification document(s): [this document] Comments: Client Hint for feature discovery 9. Implementation Status *Note to RFC Editor:* Please remove this section before publication. *Specification status:* Exploratory draft *Browser support:* Not yet implemented (proposed specification) Hardt & Goto Expires 9 July 2026 [Page 14] Internet-Draft Redirect Headers January 2026 *Server support:* Reference implementations needed This specification requires: * Browser vendors to implement header handling * Authorization servers to support Redirect-Query * Client applications to adopt the pattern Deployment strategy: Backward compatible - clients send both URL and headers during transition. 10. References 10.1. Normative References [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC8942] Grigorik, I. and Y. Weiss, "HTTP Client Hints", RFC 8942, DOI 10.17487/RFC8942, February 2021, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . 10.2. Informative References [OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", November 2014, . [PORTSWIGGER-OAUTH] PortSwigger, "OAuth 2.0 authentication vulnerabilities", 2024, . [RFC9700] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, January 2025, . [SAML] Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", March 2005, . Hardt & Goto Expires 9 July 2026 [Page 15] Internet-Draft Redirect Headers January 2026 Appendix A. OAuth Example: Before and After This appendix provides a detailed comparison of OAuth flows with and without Redirect Headers to illustrate the differences in security and functionality. A.1. Without Redirect Headers (current OAuth) *Client Website returns to Browser:* HTTP/1.1 303 See Other Location: https://as.example/authorize?client_id=abc&state=123&redirect_uri=... *Browser navigates, sends to AS:* GET /authorize?client_id=abc&state=123&redirect_uri=... Host: as.example Referer: https://app.example/login The Referer header is unreliable and may be stripped by browsers or proxies. *AS returns code to Browser:* HTTP/1.1 303 See Other Location: https://app.example/cb?code=SplxlOBe&state=123 The authorization code is now exposed in the URL. *Browser sends code to Client Website:* GET /cb?code=SplxlOBe&state=123 Host: app.example Referer: https://as.example/consent The authorization code is stored in browser history, server logs, and analytics systems. Third-party resources loaded by this page will receive the code via the Referer header. *Problems:* * Authorization code appears in URL (history, logs, Referer, extensions) * No cryptographic origin verification (Referer is optional and unreliable) Hardt & Goto Expires 9 July 2026 [Page 16] Internet-Draft Redirect Headers January 2026 A.2. With Redirect Headers *Client Website returns to Browser:* HTTP/1.1 303 See Other Location: https://as.example/authorize Redirect-Query: "client_id=abc&state=123&redirect_uri=https://app.example/portal/callback" Redirect-Path: "/portal/" *Browser validates and adds origin:* The browser validates the Redirect-Path claim against the current page URL. In this example, the current page is https://app.example/portal/login and the Redirect-Path claim is /portal/. Since the page path starts with /portal/, validation succeeds and the browser sets Redirect-Origin to https://app.example/ portal/. *Browser navigates, sends to AS:* GET /authorize Host: as.example Redirect-Origin: "https://app.example/portal/" Redirect-Query: "client_id=abc&state=123&redirect_uri=https://app.example/portal/callback" The Redirect-Origin is browser-supplied and cannot be spoofed. Parameters are transmitted in headers, not in the URL. *AS validates and returns to Browser:* The AS verifies that Redirect-Origin is https://app.example/portal/ and that the redirect_uri starts with https://app.example/portal/. HTTP/1.1 303 See Other Location: https://app.example/portal/callback Redirect-Query: "code=SplxlOBe&state=123" The authorization code is transmitted in the header. No parameters appear in the URL. *Browser forwards back to Client Website:* The browser is now on the AS consent page at https://as.example/ consent. Since Redirect-Query is present in the response, the browser sets Redirect-Origin to https://as.example/. Hardt & Goto Expires 9 July 2026 [Page 17] Internet-Draft Redirect Headers January 2026 GET /portal/callback Host: app.example Redirect-Origin: "https://as.example/" Redirect-Query: "code=SplxlOBe&state=123" The URL is clean with no query parameters. The client verifies that Redirect-Origin matches the expected AS. The authorization code never appears in the URL, browser history, or Referer headers. *Benefits:* * Authorization code never appears in URLs * Mutual origin authentication (browser-verified) * Backward compatible (browsers/servers without support fall back to URL parameters) *Requirements:* * If Redirect-Query received in request: AS MUST use Redirect-Query for response * Client MUST verify Redirect-Origin matches expected AS * AS MUST verify Redirect-Origin matches expected client * When Redirect-Query is present, client MUST ignore URL parameters and use only header parameters Appendix B. Acknowledgments The authors would like to thank early reviewers for their valuable feedback and insights that helped shape this proposal: Jonas Primbs, Warren Parad. Authors' Addresses Dick Hardt Hellō Email: dick.hardt@gmail.com Sam Goto Google Email: goto@google.com Hardt & Goto Expires 9 July 2026 [Page 18]