Re: [OAUTH-WG] OAuth for Browser-Based Apps

[Justin Richer]

I think it does warrant mentioning, because the main assumptions about an spa 
are that everything goes from the browser to the api itself. It might be 
surprising to a user or even a naive developer that every request goes through 
another party as a black box. Even if it's all first party abd deployed 
together, that model should be called out by the draft as an assumption for 
privacy. After all, this section is for considerations - things you should 
think about that might not be obvious.

- Justin

From: Philippe De Ryck 
Sent: Sunday, March 24, 2024 5:40 AM
To: Justin Richer 
Cc: oauth 
Subject: Re: [OAUTH-WG] OAuth for Browser-Based Apps

Hi Justin,

Thank you for your detailed review.

> §9+ this draft should add privacy considerations, particularly for BFF 
> pattern's proxy architecture.e

I wanted to ask for a bit more context on this comment. I understand that 
having a proxy as a separate entity would expose all requests/responses to this 
entity. However, in the context of a BFF, the frontend and the BFF belong 
together (i.e., they are one application deployed as two components). The 
frontend and BFF are deployed and operated by the same party, so I’m not sure 
if this comment effectively applies.

Looking forward to hearing from you.

Philippe
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth for Browser-Based Apps

[Philippe De Ryck]

Hi Justin,

Thank you for your detailed review. 

> §9+ this draft should add privacy considerations, particularly for BFF 
> pattern's proxy architecture.e

I wanted to ask for a bit more context on this comment. I understand that 
having a proxy as a separate entity would expose all requests/responses to this 
entity. However, in the context of a BFF, the frontend and the BFF belong 
together (i.e., they are one application deployed as two components). The 
frontend and BFF are deployed and operated by the same party, so I’m not sure 
if this comment effectively applies. 

Looking forward to hearing from you.

Philippe
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth for Browser-Based Apps

[Justin Richer]

As promised at the last meeting, I have been able to do a full review of the 
OAuth for Browser Based Applications draft spec, and my notes are attached, 
indexed by sections and paragraphs where possible.

Even though my notes are extensive, I do want to say that overall the document 
is in great shape and I think it offers great guidance and necessary support to 
application developers. Many of my comments focus around clarifying intent, 
consistency in language, and addressing specific concerns like when the 
document might be too opinionated (or not opinionated enough).

Thank you to the authors for this momentous work!

— Justin




OAuth for browser-based apps

Title and throughout: should we use "applications" instead of "apps"? The 
document is not consistent.

§1:

¶1 should be specific here and elsewhere:
"implementing OAuth 2.0" -> "implementing OAuth 2.0 clients"

¶2 perhaps "is known as" or "is referred to" instead of nicknamed?

BCP for native apps should be the reference, not the RFC

"implement OAuth clients"

¶3 perhaps "This specification, OAuth 2.0 for Browser-Based Apps, ..."

"implementing OAuth <> native apps and browser-based apps"

§2: nit, there's a BCP to reference here instead of 2119 directly

§3: if not expanding "app" to "application" throughout, perhaps call out here, 
even though it's fairly obvious it doesn't hurt

¶4 does "this" refer to the phrase "JavaScript applications" or the document as 
a whole and its recommendations?

§4:

¶1 the use of "were" is confusing here since OAuth 2.0 is considered one 
protocol framework; perhaps rephrase:

"At the time that OAuth 2.0 was initially specified in [RFC6749] and 
[RFC6750],"

"authorization code flow" -> "authorization code grant type" ... and throughout 
the rest of the document, generally change "flow" to "grant type" when 
referring to the official grant names. same applies to "implicit" flow and any 
others

"this was one" -> "this limitation(?) was one"

¶3 add a reference for CORS?

exposure of tokens is not the problem for refresh tokens historically, it's 
been the lack of client credentials in SPAs and poor storage mechanisms to go 
with the refresh token

¶4 second sentence has many asides and parentheticals and is hard to follow, 
suggest rewording


§5 does "JavaScript" here also refer to other browser-based execution 
languages, or is this advice JavaScript only? The definition in §3 only calls 
out "JavaScript application" specifically, not "JavaScript" being used as a 
generic in general

¶1 remove commas from "vectors, such as ... files, give an"

¶2 "JS" -> "JavaScript" (and elsewhere), or expand and define on first use

is the bold formatting really necessary to make this point?

¶3 perhaps instead of "the first part" and "the second part", link sections 
directly and number them specifically (5.1, 5.2) so as to prevent the reader 
from tripping over what constitutes the first or second "part"

¶4 it feels odd to introduce what other sections will do in this section, but 
I'm not sure where else to put this pointer, which is likely helpful to the 
reader if they're going all the way through the document

§5.1 suggest removal of "range from trivial to sophisticated" as it implies 
ranking even though the next sentence says there is no implied ranking; and 
adversarial toolkits can sometimes make sophisticated attacks trivial to 
execute in practice.

§5.1.1 why does this scenario underestimate the capabilities of an attacker? It 
is real and can cause damage. I think what might be intended here is that if a 
developer focuses only on thwarting this trivial attack they are 
underestimating an attacker's ability, is that the case? In any event perhaps 
such value judgement isn't helpful unless it's tied to specific guidance for 
the reader.

§5.1.2 the attack in §5.1.1 does not depend on theft of token from the payload 
of the token response but rather from storage; is this difference intended? or 
is "the payload" meant to refer to the attacker's payload of malicious code?

¶2 I believe the second bullet list is supposed to have a sub-list, but this 
was not rendered as such in the version I reviewed

§5.1.3

"Setup" -> "set up"

add reference for "Web Messaging"?

It should be noted that a precondition to step (3) is that it's only possible 
if the authz code can be issued silently and in a frame context, or else the 
payload would need to manipulate the AS into doing so; this is mentioned in the 
closing paragraph but it felt out of place not to put it sooner

§5.2.1 nit, it's not impersonation of the user so much as impersonation of the 
legitimate client application

§5.2.2 same nit as above, not the user but the client; any other place this 
appears should also be aligned

¶2: suggest "considers the access token to be valid" -> "accepts the valid 
access token".

¶5 the "additionally" doesn't follow from the preceding text, suggest pulling 
it out or re-ordering the topics here

§5.2.3

¶2 CORS 

Re: [OAUTH-WG] OAuth for Browser-Based Apps Draft 12

[Aaron Parecki]

Thank you, you're absolutely correct. I've updated a few uses of that to
something hopefully more accurate. There are a few more uses of "DOM" still
and I would love someone who has more experience with browsers than me to
review those for accuracy as well! Thanks!

Latest editor's draft:

https://drafts.oauth.net/oauth-browser-based-apps/draft-ietf-oauth-browser-based-apps.html

Aaron

On Wed, Dec 7, 2022 at 12:52 AM Thomas Broyer  wrote:

>
>
> On Wed, Dec 7, 2022 at 1:07 AM Aaron Parecki  40parecki@dmarc.ietf.org> wrote:
>
>> Hi all,
>>
>> I just published a revised version of OAuth for Browser-Based Apps based
>> on the feedback and discussion at IETF 115 London!
>>
>>
>> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-12.html
>>
>> The primary changes are:
>>
>> * Rephrased the architecture patterns to focus on token acquisition
>>
>
> Terminology-wise, the phrasing "code executed in the DOM" is not correct:
> the DOM is an API for manipulating the document. This should rather be
> "code executed in a browsing context" or possibly "code executed in a
> document context" (or just "in a document"?), as opposed to a "worker
> context" or service worker.
>
> Anyway, thanks for that work. I'm only using the drafts as reference in
> architecture discussions and am looking forward to this turning into an RFC.
> --
> Thomas Broyer
> /tɔ.ma.bʁwa.je/ 
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth for Browser-Based Apps Draft 12

[Thomas Broyer]

On Wed, Dec 7, 2022 at 1:07 AM Aaron Parecki  wrote:

> Hi all,
>
> I just published a revised version of OAuth for Browser-Based Apps based
> on the feedback and discussion at IETF 115 London!
>
> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-12.html
>
> The primary changes are:
>
> * Rephrased the architecture patterns to focus on token acquisition
>

Terminology-wise, the phrasing "code executed in the DOM" is not correct:
the DOM is an API for manipulating the document. This should rather be
"code executed in a browsing context" or possibly "code executed in a
document context" (or just "in a document"?), as opposed to a "worker
context" or service worker.

Anyway, thanks for that work. I'm only using the drafts as reference in
architecture discussions and am looking forward to this turning into an RFC.
-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth for Browser-Based Apps Draft 12

[Aaron Parecki]

Hi all,

I just published a revised version of OAuth for Browser-Based Apps based on
the feedback and discussion at IETF 115 London!

https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-12.html

The primary changes are:

* Rephrased the architecture patterns to focus on token acquisition
* Added a new section about the various options available for storing tokens
* Added a section on sender-constrained tokens and a reference to DPoP
* Added a section discussing why not to use the Cookie API to store tokens

At this point there are no open issues on GitHub, and I have nothing else I
am planning on adding to the document. Please review if you are interested
and let me know if you have any further suggestions!

Aaron Parecki
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth