Hey I have submitted draft-hardt-oauth-protected-authorization, which defines browser support for protecting OAuth authorization requests and responses in redirect-based flows.
https://datatracker.ietf.org/doc/draft-hardt-oauth-protected-authorization/ This is the successor to the Redirect Headers draft I mentioned here in December [1]. It was presented in HTTPBIS at IETF 125, and the feedback there was clear: the interesting properties are OAuth-specific. The generic mechanism is gone, and the draft is now scoped to OAuth and written for this group. The problem is one this list has been circling since 2011: the authorization code is a credential, and we deliver it in a URL. RFC 6819 cataloged the exposure vectors (section 4.4.1.1: Referer, browser history, server logs), and RFC 9700 devotes sections 4.2 through 4.5 to the same family. The recent Browser-Swapping thread [2] and Jonas Primbs' presentation at IETF 124 [3] showed that a code sitting in a URL bar or in history is still exploitable today, and Andrey Kuznetsov asked in October why form_post gets so little attention given that it keeps the code out of the URL [4]. PKCE, one-time use, short lifetimes, and iss all limit the damage of an exposed code. None of them remove the exposure. This draft removes the exposure. A single browser-protected Structured Field header, OAuth-Authorization, is set by the client alongside a standard authorization request, and by the AS in place of the response parameters in the redirect URI. The browser attests the origin of the redirecting party on each leg, delivers the authorization response exactly once to the redirect URI, and shields the header from page JavaScript, service workers, and browser extensions. A browser that cannot enforce those protections must not implement the mechanism, and the flow then degrades to standard OAuth. Properties: - The authorization code, and the rest of the authorization response, never appears in any URL: nothing in history, nothing in logs, nothing in Referer, nothing to swap between browsers. - The AS receives a browser-attested, tamper-evident statement of which origin initiated the request, and the client receives a browser-attested statement of which origin returned the response. The latter complements iss (RFC 9207) and is stronger: iss is asserted by whichever server sends the response. - It complements PKCE, PAR, iss, and JARM, and replaces none of them. - Deployment is incremental with no coordination: for most clients it is a library update, and the AS switches to protected responses only when the header's arrival with the request proves the browser and client both support it. Everything else remains standard OAuth. Sam Goto (Google Chrome Team) is co-author. Browser behavior will be specified in a WHATWG Fetch PR; this draft defines the OAuth semantics. A design rationale appendix addresses the alternatives raised at IETF 125, including cryptographic protection of parameters, moving to the back channel, a Sec- prefix, and form_post. Editor's copy and issue tracker: https://dickhardt.github.io/oauth-protected-authorization/draft-hardt-oauth-protected-authorization.html https://github.com/dickhardt/oauth-protected-authorization Feedback welcome. Hopefully there will be time on the agenda at the next meeting. Dick [1] https://mailarchive.ietf.org/arch/msg/oauth/FFkUlOiz7I4K03pqjMfIFkxAwA8/ [2] https://mailarchive.ietf.org/arch/msg/oauth/K8Wnw08GzPstyAQAh0JmSB47pOQ/ [3] https://datatracker.ietf.org/meeting/124/materials/slides-124-oauth-sessa-browser-swapping-01 [4] https://mailarchive.ietf.org/arch/msg/oauth/TskANcfNy7NNir-hbmcmFASDVog/
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
