Yes, I meant response_mode. Thanks. And those are good points about the referrer policy. Thanks for that insight as well.
In the context of this thread/topic, I'm assuming browser-based JS clients, and a common deployment is from a CDN, so I suspect the <meta> tag approach for a referrer policy is sufficient (especially since many SPAs are designed for CDN deployment)? -Brock On 12/9/2018 3:00:23 AM, David Waite <[email protected]> wrote: I assume the original post meant response_mode, not response_type. Fragments have their own data leakage problems, in particular they are preserved on 3xx redirects (per https://tools.ietf.org/html/rfc7231#section-7.1.2 [https://tools.ietf.org/html/rfc7231#section-7.1.2]). The form_post mode is the safest, but unfortunately was not defined in the original specifications so it doesn’t have as widespread support. In the absence of a response_mode RFC, I would typically suggest both killing the code in the referrer as part of processing, and a server-wide Referrer Policy of never or origin (as those have reasonably broad support) as server-wide response headers are easier to operationally audit. -DW On Dec 8, 2018, at 3:53 PM, Brock Allen <[email protected] [mailto:[email protected]]> wrote: Not pure OAuth. This only came up as a question while I was implementing code flow/pkce for oidc-client-js. I can appreciate not expanding the current OAuth2 behavior in the BCP, so that's fair. I only wanted to mention it in case it had not been considered. Having said that, I think I will implement an optional response_type in my code flow/pkce to allow fragment, but default to query (as that's the default for pure code flow). -Brock
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
