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

Please keep in mind that these referrer removing standards are relatively new and do not work in older browsers. Sensitive data of any kind in URL’s is still a very basic insecure coding practice and has no place in standards. Check out caniuse for how fractured support is for even modern browsers. IE, Edge and Safari iOS still have only partial support.

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Dec 9, 2018, at 9:23 AM, Filip Skokan <panva.ip@gmail.com> wrote:
> 
> As David suggested,
> 
> it is easier to get rid of the code from a query using a referrer policy header or a meta than getting rid of a fragment which would require the each client to have a javascript snippet rewriting the current window.location.hash
> 
> S pozdravem,
> Filip Skokan
> 
> 
>> On Sun, Dec 9, 2018 at 2:53 PM Brock Allen <brockallen@gmail.com> wrote:
>> 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 <david@alkaline-solutions.com> 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). 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 <brockallen@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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth