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

From: "Brock Allen" <[email-masked]>
Date: Sat, 08 Dec 2018 10:29:09 -0500

Should the BCP suggest using OIDC's response_type=fragment as the mechanism for returning the code from the AS? Or simply suggest using the fragment component of the redirect_uri for the code, without a response_type parameter (IOW don't allow it to be dynamic)?

-Brock

---

From: Aaron Parecki <[email-masked]>
Date: Sat, 8 Dec 2018 10:23:27 -0800

What would be the benefit of using this response type? Are you aware of any
OAuth (not OIDC) clients that do this today?

- Aaron

On Sat, Dec 8, 2018 at 7:29 AM Brock Allen <[email-masked]> wrote:

> Should the BCP suggest using OIDC's response_type=fragment as the
> mechanism for returning the code from the AS? Or simply suggest using the
> fragment component of the redirect_uri for the code, without a
> response_type parameter (IOW don't allow it to be dynamic)?
>
> -Brock
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: "Brock Allen" <[email-masked]>
Date: Sat, 08 Dec 2018 13:33:42 -0500

For the same reason the implicit flow uses it -- to reduce exposure of the response params. I know the code is protected with the code_verifier, but it wouldn't hurt to reduce its exposure, no?

-Brock

On 12/8/2018 1:23:41 PM, Aaron Parecki <[email-masked]> wrote:
What would be the benefit of using this response type? Are you aware of any OAuth (not OIDC) clients that do this today?

- Aaron

On Sat, Dec 8, 2018 at 7:29 AM Brock Allen <[email-masked] [mailto:[email-masked]]> wrote:

-Brock

_______________________________________________
OAuth mailing list
[email-masked] [mailto:[email-masked]]
https://www.ietf.org/mailman/listinfo/oauth [https://www.ietf.org/mailman/listinfo/oauth]

---

From: Aaron Parecki <[email-masked]>
Date: Sat, 8 Dec 2018 10:57:52 -0800

Do you know of anyone currently doing this today in an OAuth-only
application?

If the group wanted to take some existing OIDC mechanisms and apply them to
OAuth, I feel like that needs to happen in a separate RFC, and that's a
much bigger discussion. This BCP shouldn't really be defining new behavior.
It's similar to how "OAuth 2.0 for Mobile and Native Apps" is not where
PKCE is defined, PKCE has its own RFC.

- Aaron

On Sat, Dec 8, 2018 at 10:33 AM Brock Allen <[email-masked]> wrote:

> For the same reason the implicit flow uses it -- to reduce exposure of the
> response params. I know the code is protected with the code_verifier, but
> it wouldn't hurt to reduce its exposure, no?
>
> -Brock
>
> What would be the benefit of using this response type? Are you aware of
> any OAuth (not OIDC) clients that do this today?
>
> - Aaron
>
>

---

From: "Brock Allen" <[email-masked]>
Date: Sat, 08 Dec 2018 17:53:15 -0500

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

On 12/8/2018 1:58:05 PM, Aaron Parecki <[email-masked]> wrote:
Do you know of anyone currently doing this today in an OAuth-only application?

If the group wanted to take some existing OIDC mechanisms and apply them to OAuth, I feel like that needs to happen in a separate RFC, and that's a much bigger discussion. This BCP shouldn't really be defining new behavior. It's similar to how "OAuth 2.0 for Mobile and Native Apps" is not where PKCE is defined, PKCE has its own RFC.

- Aaron

On Sat, Dec 8, 2018 at 10:33 AM Brock Allen <[email-masked] [mailto:[email-masked]]> wrote:

-Brock

On 12/8/2018 1:23:41 PM, Aaron Parecki <[email-masked] [mailto:[email-masked]]> wrote:
What would be the benefit of using this response type? Are you aware of any OAuth (not OIDC) clients that do this today?

- Aaron

-Brock

---

From: David Waite <[email-masked]>
Date: Sun, 9 Dec 2018 01:00:21 -0700

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-masked]> wrote:
>

---

From: "Brock Allen" <[email-masked]>
Date: Sun, 09 Dec 2018 08:53:06 -0500

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-masked]> 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.

-DW

On Dec 8, 2018, at 3:53 PM, Brock Allen <[email-masked] [mailto:[email-masked]]> wrote:

-Brock

---

From: Filip Skokan <[email-masked]>
Date: Sun, 9 Dec 2018 15:23:13 +0100

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 <[email-masked]> wrote:

> 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
>
> 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
>
> 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
>
>

---

From: Jim Manico <[email-masked]>
Date: Sun, 9 Dec 2018 10:22:24 -0500

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 <[email-masked]> 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
> 
> 
>>> 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.
>>>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 10 Dec 2018 11:03:08 -0700

For what it's worth, the response_mode parameter is defined in OAuth 2.0
Multiple Response Type Encoding Practices
<https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html>, which
is an OIDF document but not strictly part of OIDC so it can be used and
referenced as an extension of OAuth without going fully OIDC.

One of the purported benefits of fragment encoding was that it allowed for
the redirect uri request to be served from browser cache.

On Sat, Dec 8, 2018 at 11:58 AM Aaron Parecki <[email-masked]> wrote:

> If the group wanted to take some existing OIDC mechanisms and apply them
> to OAuth, I feel like that needs to happen in a separate RFC, and that's a
>> For the same reason the implicit flow uses it -- to reduce exposure of
>> the response params. I know the code is protected with the
>> code_verifier, but it wouldn't hurt to reduce its exposure, no?
>>
>> -Brock
>>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._