Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps and response_type/fragment

["Brock Allen" <[e-mail]>]

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 <[e-mail]> 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 <[e-mail] [mailto:[e-mail]]> 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