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 <brockal...@gmail.com> 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
