Re: [OAUTH-WG] WGLC for Browser-based Apps

[Yannick Majoros <[e-mail]>]

That's outside of the responsibility of a BFF. That's what web application
firewalls are doing, with disputable results. They are another tool that
can be used, for any of the described flows btw.

Le lun. 28 août 2023, 18:14, Dick Hardt <[e-mail]> a écrit :

> While a breach of a BFF may be as catastrophic as an exfiltration of an
> access token, the BFF may also be more secure against a breach.
>
> For example, a BFF could detect a possible compromise by the API usage
> pattern becoming unusual to the app, that a RS is not able to detect as the
> general usage patterns are less defined, and the BFF could then stop
> processing requests.
>
>
>
>
> On Mon, Aug 28, 2023 at 8:58 AM Aaron Parecki <aaron=
> [e-mail]> wrote:
>
>> > An XSS compromise would allow an attacker to call the resource server
>> from the browser context through the BFF, which would lead to the same
>> catastrophous result as doing it from another context.
>>
>> There is a huge difference between being able to access resources through
>> the user's browser while it's online vs being able to access resources
>> without the browser's involvement.
>>
>> Additionally, in many cases, the BFF exposes only a subset of actions of
>> the resource server to the client. Or put another way, sometimes access
>> tokens can access more resources than just the ones the BFF can access.
>> This obviously doesn't apply to everyone, but it's still common enough to
>> be significant. This is briefly mentioned in the security considerations
>> already:
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-reducing-the-impact-of-toke
>>
>> Aaron
>>
>>
>> On Mon, Aug 28, 2023 at 8:51 AM Yannick Majoros <[e-mail]>
>> wrote:
>>
>>> An XSS compromise would allow an attacker to call the resource server
>>> from the browser context through the BFF, which would lead to the same
>>> catastrophous result as doing it from another context.
>>>
>>> Cookies are sent automatically, potentially to resources which shouldn't
>>> get it. Same threat level as a token that is too broadly scoped, really.
>>>
>>> You really have a point about refresh tokens here, but they are a
>>> separate, real issue. Refresh tokens should be avoided whenever you can do
>>> without. Any pattern that can keep them safe is on the same level, but
>>> their safety is always relative. They make any attack worse, indeed (and
>>> that is also true for BFFs in some scenario's). This isn't specifically
>>> about BFFs.
>>>
>>> Le lun. 28 août 2023 à 17:38, Aaron Parecki <[e-mail]> a
>>> écrit :
>>>
>>>> > BFFs are not any safer, XSS or any successful malicious javascript
>>>> execution has the same end effect
>>>>
>>>> As described in the draft as well as in this email thread, this is
>>>> incorrect.
>>>>
>>>> An XSS compromise of the BFF architecture results in the attacker being
>>>> able to make requests to the BFF with the legitimate user's cookie, as long
>>>> as the user's browser is active. An XSS compromise of a SPA results in the
>>>> attacker being able to obtain access tokens (and possible refresh tokens),
>>>> which results in the attacker being able to access the resource server
>>>> directly, outside of the context of the user's browser, which may allow the
>>>> attacker to access far more data than the browser app alone, and for a
>>>> longer period of time.
>>>>
>>>> The difference between these threats is extremely significant.
>>>>
>>>> Aaron
>>>>
>>>> On Mon, Aug 28, 2023 at 8:14 AM Yannick Majoros <[e-mail]>
>>>> wrote:
>>>>
>>>>> My last comment was rather ironic: user-facing applications are
>>>>> dangerous (security is hard, which I say nothing with), and that is true
>>>>> for any scheme.. BFFs are not any safer, XSS or any successful malicious
>>>>> javascript execution has the same end effect (=game over, complete
>>>>> compromise of authenticated calls), and there was still no
>>>>> factual demonstration of multiple levels of security here. See my detailed
>>>>> explanations.
>>>>>
>>>>> Le lun. 28 août 2023 à 11:35, Steinar Noem <[e-mail]> a
>>>>> écrit :
>>>>>
>>>>>> I think this is a great discussion, and it seems to me that Yannicks
>>>>>> last comment is basically what Phillippe is trying to point out..
>>>>>> I just wanted to remind the authors about a couple of things that we
>>>>>> briefly discussed during OSW in London.
>>>>>>
>>>>>> Although it might not be directly relevant for this discussion I do
>>>>>> think that it might be a good idea that the spec mentions that:
>>>>>>
>>>>>>    - The level of security you require for any client is often a
>>>>>>    reflection of the sensitivity of the information that the API exposes. You
>>>>>>    will have different requirements for confidential information than for open
>>>>>>    data. An example of a similar recommendation can be found in the HTTP
>>>>>>    Semantics specification: https://httpwg.org/specs/rfc9110.html#GET
>>>>>>
>>>>>>    - In my domain it is most often the owner of the API (the data
>>>>>>    controller) who defines and approves the level of security which it finds
>>>>>>    to fit their responsibilities (e.g. legal obligations) - although in some
>>>>>>    cases it might be both the data provider and the data consumer. Meaning -
>>>>>>    this BCP might be equally important for the API-owner as it is to the
>>>>>>    client developer.
>>>>>>    - I think this discussion shows that any mitigation on the
>>>>>>    browser side will only raise the bar for the attacker, and can never be a
>>>>>>    fully effective countermeasure. I think this point could be even more
>>>>>>    clearly stated early in the spec, and that both the API-owner or client
>>>>>>    owner should be aware of this risk, and select their appropriate choice of
>>>>>>    security measures based on a risk assessment. In some cases their
>>>>>>    conclusion might be that a browser based app is not secure enough for
>>>>>>    their responsibilities.
>>>>>>
>>>>>>
>>>>>> S
>>>>>>
>>>>>> søn. 27. aug. 2023 kl. 18:41 skrev Yannick Majoros <[e-mail]
>>>>>> >:
>>>>>>
>>>>>>> Yes, but this is true for all flows. Web applications are dangerous.
>>>>>>> Applications handling user input are dangerous too.
>>>>>>>
>>>>>>> Le dim. 27 août 2023, 17:46, Tom Jones <[e-mail]>
>>>>>>> a écrit :
>>>>>>>
>>>>>>>> You can write your code as strong as you wish. You cannot determine
>>>>>>>> if the code running in the computer is that code running unaltered.
>>>>>>>> ..tom
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Aug 27, 2023 at 5:25 AM Yannick Majoros <[e-mail]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Thanks for taking the time to respond and for the constructive
>>>>>>>>> feedback.
>>>>>>>>>
>>>>>>>>> Still, there is some initial incorrect point that makes the rest
>>>>>>>>> of the discussion complicated, and partly wrong.
>>>>>>>>>
>>>>>>>>> Specifically, §6.4.2.1 says this: *The service worker MUST NOT
>>>>>>>>> transmit tokens, authorization codes or PKCE code verifier to the frontend
>>>>>>>>> application.*
>>>>>>>>>
>>>>>>>>> Wording should be refined, but the idea is that the service worker
>>>>>>>>> is to actually restrict authorization codes from even reaching the
>>>>>>>>> frontend. Of course, easier said than done, but that part happens to be
>>>>>>>>> quite easy to implement.
>>>>>>>>>
>>>>>>>>> This has further impact on much of the other statements:
>>>>>>>>> *> The main problem with a browser-only client is that the
>>>>>>>>> attacker with control over the client has the ability to run a silent
>>>>>>>>> Authorization Code flow, which provides them with an independent set of
>>>>>>>>> tokens*
>>>>>>>>> [...]
>>>>>>>>> *> **The security differences between a BFF and a browser-only
>>>>>>>>> app are not about token storage, but about the attacker being able to run a
>>>>>>>>> new flow to obtain tokens.*
>>>>>>>>> [...]
>>>>>>>>> *> Again, the security benefits of a BFF are not about stoken
>>>>>>>>> storage. Even if you find the perfect storage solution for non-extractable
>>>>>>>>> tokens in the browser, an attacker still controls the client application
>>>>>>>>> and can simply request a new set of tokens. *
>>>>>>>>>
>>>>>>>>> Truth is: no, you can't start a new authentication flow and get
>>>>>>>>> the authorization code back in the main thread. I'm talking about the
>>>>>>>>> redirection scenario, which I'm the most familiar with, but it would
>>>>>>>>> probably apply to the "message" one as well (which is new to me and seems
>>>>>>>>> to be ashtoningly legit due to vague "for example" wording in the OAuth2
>>>>>>>>> spec :-) ).
>>>>>>>>>
>>>>>>>>> The service worker, according to
>>>>>>>>> https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope/fetch_event#description
>>>>>>>>> , just intercepts the authorization code, gets a token, and never sends it
>>>>>>>>> back to the main code.
>>>>>>>>>
>>>>>>>>> But don't trust me on my words: what about demonstrating our
>>>>>>>>> claims with actual code, and as such create a shorter, simpler, but more
>>>>>>>>> constructive discussion?
>>>>>>>>>
>>>>>>>>> The demonstration in its current form would not lead to a
>>>>>>>>> successful compromise of a good implementation of access tokens handled by
>>>>>>>>> a service worker.
>>>>>>>>>
>>>>>>>>> Yannick
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le sam. 26 août 2023 à 14:20, Philippe De Ryck <
>>>>>>>>> [e-mail]> a écrit :
>>>>>>>>>
>>>>>>>>>> My responses inline.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi everyone,
>>>>>>>>>>
>>>>>>>>>> The document is about "OAuth 2.0 for Browser-Based Apps". Its
>>>>>>>>>> abstract further explains that it "details the security considerations and
>>>>>>>>>> best practices that must be taken into account when developing
>>>>>>>>>> browser-based applications that use OAuth 2.0.".
>>>>>>>>>>
>>>>>>>>>> As such, detailing security considerations is important. I share
>>>>>>>>>> the point of view that basing web applications on proven concepts is
>>>>>>>>>> important. The approaches detailed in the document have all their
>>>>>>>>>> advantages and disadvantages.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> We have discussed the topic of browser-based apps in depth at the
>>>>>>>>>> OAuth Security Workshop last week. I am also working with Aaron Parecki on
>>>>>>>>>> updating the specification to more accurately reflect these advantages and
>>>>>>>>>> disadvantages. Updates will go out in the coming days/weeks, so we more
>>>>>>>>>> than welcome concrete feedback on the content there.
>>>>>>>>>>
>>>>>>>>>> There are 2 main approaches to browser-based applications
>>>>>>>>>> security. One of them is to store security credentials at the frontend. The
>>>>>>>>>> other one is to use cookies and a BFF. Though common practice, there is
>>>>>>>>>> nothing fundamentally more secure about them in a demonstrable way.
>>>>>>>>>> Different approaches, different characteristics and security assumptions.
>>>>>>>>>> Nobody can prove that either approach is better, just that there are
>>>>>>>>>> different concerns.
>>>>>>>>>>
>>>>>>>>>> Handling security in BFFs relies on cookies that cannot be read
>>>>>>>>>> by the javascript application. This mechanism provides some reliable
>>>>>>>>>> protection about the cookie itself that is used as a kind of credential to
>>>>>>>>>> access confidential web resources. It obviously demands some additional
>>>>>>>>>> layers in the flow (proxy or light server). You also need a mechanism to
>>>>>>>>>> share session information, either at the server side, or for example by
>>>>>>>>>> having the cookie itself hold that information. A bigger concern to me is
>>>>>>>>>> that you basically give up standard mechanisms for securing the flow
>>>>>>>>>> between the frontend and the backend: the security between the two is a
>>>>>>>>>> custom solution (based on cookies, in a specific, custom way, this part
>>>>>>>>>> being in no way OAuth or standard). This solves the problem by not using
>>>>>>>>>> OAuth at all in the browser part of the application, basically making the
>>>>>>>>>> client application purely backend. However, the fact that browser-based
>>>>>>>>>> applications cannot be secured with OAuth isn't universally true, and
>>>>>>>>>> strongly depends on one's definition of "secure", and basically comes down
>>>>>>>>>> to what the security issue is.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The updated specification will clearly outline the security
>>>>>>>>>> considerations when making the browser-based application a public OAuth
>>>>>>>>>> client.
>>>>>>>>>>
>>>>>>>>>> *The main problem with a browser-only client is that the attacker
>>>>>>>>>> with control over the client has the ability to run a silent Authorization
>>>>>>>>>> Code flow, which provides them with an independent set of tokens.*
>>>>>>>>>> These tokens give the attacker long-term and unrestricted access in the
>>>>>>>>>> name of the user. A BFF-based architecture does not suffer from this issue,
>>>>>>>>>> since the OAuth client is a confidential client. Regardless of one’s
>>>>>>>>>> definition of “secure”, this is a clear difference on the achievable level
>>>>>>>>>> of security.
>>>>>>>>>>
>>>>>>>>>> Of course, as stated multiple times before, the use of a BFF does
>>>>>>>>>> not eliminate the presence of the malicious JS, nor does it solve all abuse
>>>>>>>>>> scenarios.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Storing tokens at the frontend has advantages: it solves my
>>>>>>>>>> concern above about a standard based flow between the frontend and the
>>>>>>>>>> backend.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The use of cookies is a core building block of the web, and is
>>>>>>>>>> quite standard.
>>>>>>>>>>
>>>>>>>>>> It's simpler from an operational point of view. And it's been
>>>>>>>>>> used in the wild for ages.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Anyone using a browser-only client should be informed about the
>>>>>>>>>> clear and significant dangers of this approach, which the updated
>>>>>>>>>> specification will do.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Both flows have been compromised numerous times. This doesn't
>>>>>>>>>> mean they are not right by design, but that the specific security concerns
>>>>>>>>>> have to be addressed.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If you have specific security concerns about a BFF, I’d suggest
>>>>>>>>>> raising them. Until now, I have only seen arguments that highlight the
>>>>>>>>>> additional effort it takes to implement a BFF, but nothing to undermine its
>>>>>>>>>> security. Plenty of highly sensitive applications in the healthcare and
>>>>>>>>>> financial industry opt for a BFF for its improved security properties and
>>>>>>>>>> consider this trade-off to be favorable.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Now, the concerns we are really discussing is, what happens in
>>>>>>>>>> case of XSS or any form of malicious javascript.
>>>>>>>>>>
>>>>>>>>>> In this case, for all known flows, session riding is the first
>>>>>>>>>> real issue. Whether the injected code calls protected web resources through
>>>>>>>>>> the BFF or using the stored tokens, is irrelevant: the evil is done. Seeing
>>>>>>>>>> different threat levels between token abuse and session riding is a logical
>>>>>>>>>> shortcut: in many cases, the impact will be exactly the same.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Stating that using stolen tokens is the same as sending requests
>>>>>>>>>> through a compromised client in the user’s browser (client hijacking) is
>>>>>>>>>> categorically false. Here are two concrete differences:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    - Stolen refresh tokens give an attacker long-term access in
>>>>>>>>>>    the name of the user. Client hijacking only works as long as the user’s
>>>>>>>>>>    browser is online and the client is effectively running.
>>>>>>>>>>    - Stolen access tokens give an attacker unfettered access to
>>>>>>>>>>    any resource server that accepts it. Client hijacking forces the attacker
>>>>>>>>>>    to play by the rules of the client. For example, an attacker can abuse a
>>>>>>>>>>    stolen token with fake origin headers to access a resource server that
>>>>>>>>>>    would accept the token, but has a CORS policy that rejects requests from
>>>>>>>>>>    the client’s origin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> As stated before, the DPoP specification takes a similar point of
>>>>>>>>>> view on these consequences. They explicitly aim to prevent the abuse of
>>>>>>>>>> stolen tokens, while considering client hijacking to be out of scope (
>>>>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop#name-objectives
>>>>>>>>>> )
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On a sidenote, the term “session riding” seems to refer to CSRF,
>>>>>>>>>> not to client hijacking. I have only learned this myself recently and have
>>>>>>>>>> mis-used this term before as well. I wanted to point this out to avoid
>>>>>>>>>> further confusion.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Reducing the attack surface with a BFF or even a simple proxy is
>>>>>>>>>> a possible but separate topic: this doesn't have to be linked to where
>>>>>>>>>> tokens are stored. Alternatively, services that shouldn't be accessible
>>>>>>>>>> could simply not be exposed, and token scope and audience must be well
>>>>>>>>>> thought.
>>>>>>>>>>
>>>>>>>>>> As such, BFFs as well as frontend token storage, though
>>>>>>>>>> different, are application design choices and have no demonstrable
>>>>>>>>>> superiority from a security point of view.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *The security differences between a BFF and a browser-only app
>>>>>>>>>> are not about token storage, but about the attacker being able to run a new
>>>>>>>>>> flow to obtain tokens.*
>>>>>>>>>>
>>>>>>>>>> You also talk about “demonstrable” differences. I have shown
>>>>>>>>>> examples (both in text and video) of these consequences in browser-only
>>>>>>>>>> apps, resulting in the attacker obtaining both an access token and a
>>>>>>>>>> refresh token. If you claim that BFFs are just the same, I invite you to
>>>>>>>>>> demonstrate your point of view.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Still, it seems it matters to some people to not exfiltrate
>>>>>>>>>> tokens in case of successful XSS. In the first instance, I don't share this
>>>>>>>>>> need to protect short-lived tokens in a game over scenario, but the whole
>>>>>>>>>> investigation of more secure frontend storage mechanisms started because
>>>>>>>>>> some customers are concerned. We are in the realm of choice, not of
>>>>>>>>>> provable security need, but it is still important to them.
>>>>>>>>>>
>>>>>>>>>> Documenting security concerns and possible solutions is part of
>>>>>>>>>> the document. Where you store the tokens has an impact on how easy it will
>>>>>>>>>> be for an attacker to exfiltrate them. Local or session storage is
>>>>>>>>>> obviously not the best choice here, as injected javascript can easily
>>>>>>>>>> access it.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Again, the security benefits of a BFF are not about stoken
>>>>>>>>>> storage. Even if you find the perfect storage solution for non-extractable
>>>>>>>>>> tokens in the browser, an attacker still controls the client application
>>>>>>>>>> and can simply request a new set of tokens.
>>>>>>>>>>
>>>>>>>>>> This link points to the exact demo scenario in the video I have
>>>>>>>>>> referenced before:
>>>>>>>>>> https://youtu.be/OpFN6gmct8c?feature=shared&t=1366 It clearly
>>>>>>>>>> shows how the attacker runs a new flow to obtain tokens, without ever
>>>>>>>>>> touching the application’s tokens.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> A service worker is an interesting place to store them, as it can
>>>>>>>>>> additionally play the role of a front-end proxy that both holds the token
>>>>>>>>>> securely, and securely proxy requests to the resource server. Besides, a
>>>>>>>>>> track was started with Rifaat to initiate changes to the service worker
>>>>>>>>>> specifications to make some things simpler.
>>>>>>>>>>
>>>>>>>>>> The point that the service worker solution isn't that widespread
>>>>>>>>>> is indeed correct and should be addressed. I propose transparently
>>>>>>>>>> mentioning that it is seen as a possible but uncommon storage mechanism.
>>>>>>>>>> There should also be some explanation about other kinds of web workers,
>>>>>>>>>> which are more commonly used but exploitable, so less secure when token
>>>>>>>>>> exfiltration is a concern. The document isn't only about security best
>>>>>>>>>> practices, though, but about security concerns. Implementations are
>>>>>>>>>> explicitly out of scope.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Using a SW for storage does not solve anything, since the
>>>>>>>>>> attacker can simply request fresh tokens.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> My conclusion is that, though we can surely make the document
>>>>>>>>>> better, there is no all-encompassing solution. Similarly, BFFs are not
>>>>>>>>>> a higher level of security for healthcare of banks, just a different
>>>>>>>>>> solution. Service workers are still an interesting solution for people who
>>>>>>>>>> absolutely want to secure tokens at the frontend, and as improvable as
>>>>>>>>>> the document is, shouldn't be left out.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You, as the creator of the SW approach, have clearly stated that
>>>>>>>>>> you don’t even use it in practice, so I don’t really understand the urge to
>>>>>>>>>> make this a recommended pattern. On the contrary, BFFs are used in practice
>>>>>>>>>> in a variety of scenarios.
>>>>>>>>>>
>>>>>>>>>> That said, the SW approach should indeed be mentioned in the
>>>>>>>>>> document, to clearly illustrate the security considerations and
>>>>>>>>>> limitations.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> About some specific concerns:
>>>>>>>>>> > *While content injection attacks are still possible, the BFF
>>>>>>>>>> limits the attacker’s ability to abuse APIs by constraining access through
>>>>>>>>>> a well-defined interface to the backend which eliminates the possibility of
>>>>>>>>>> arbitrary API calls.*
>>>>>>>>>> Session riding is still the main issue and isn't addressed at
>>>>>>>>>> all. If the intention here was to limit the number of exposed endpoints,
>>>>>>>>>> the application can still be designed to either only expose what is needed,
>>>>>>>>>> or put a proxy or api manager between for limiting exposition, unrelated to
>>>>>>>>>> where token storage happen.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> No-one has ever stated that a BFF would solve the consequences of
>>>>>>>>>> an attacker hijacking a client. However, when the attacker is forced to
>>>>>>>>>> launch attacks through a client running in the user’s browser, they are
>>>>>>>>>> forced to go through the BFF. That gives you a point of control which you
>>>>>>>>>> *could* use to implement restrictions. This is not required to
>>>>>>>>>> benefit from a BFF, since the main benefit is moving from a public client
>>>>>>>>>> to a confidential client.
>>>>>>>>>>
>>>>>>>>>> You state that you can achieve the same by using a careful design
>>>>>>>>>> of the application. However, you fail to mention what you consider the
>>>>>>>>>> “application” and where exactly this restriction fits in. This is
>>>>>>>>>> important, because once the attacker has exfiltrated access tokens, they
>>>>>>>>>> can send arbitrary requests. If the resource servers are not fully shielded
>>>>>>>>>> by an API manager, the attacker can contact them directly with a stolen
>>>>>>>>>> token. And if you apply this close to the resource servers, how will you
>>>>>>>>>> then configure them to only allow certain clients to access certain
>>>>>>>>>> endpoints?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *> No, because running a silent flow in an iframe typically uses
>>>>>>>>>> a web message response. In essence, the callback is not the redirect URI,
>>>>>>>>>> but a minimal JS page that sends the code to the main application context
>>>>>>>>>> using the web messaging mechanism. The message will have the origin of the
>>>>>>>>>> authorization server as a sender. *
>>>>>>>>>> The iframe needs to get the auth code somehow, and that typically
>>>>>>>>>> happens by setting its src to the auth endpoint, and having a redirect URI
>>>>>>>>>> that points to that minimal js page. This would mean an  attacker can
>>>>>>>>>> change the redirect URI to be able to point to some custom js in the
>>>>>>>>>> application, which is a whole different
>>>>>>>>>>
>>>>>>>>>> Philippe, I'm honestly quite skeptical about that attack, but it
>>>>>>>>>> sounds interesting. Can you provide some details or a reproducer?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In all honesty, my understanding that the Web Messaging approach
>>>>>>>>>> was universally used turned out to be inaccurate. There are two concrete
>>>>>>>>>> ways to run a silent authorization code flow: (1) using
>>>>>>>>>> response_mode=web_message and (2) using the proper redirect URI. Both
>>>>>>>>>> scenarios allow the attacker to obtain the authorization code by starting
>>>>>>>>>> the flow with an authorization request that
>>>>>>>>>> *is indistinguishable* from a request coming from the legitimate
>>>>>>>>>> application.
>>>>>>>>>>
>>>>>>>>>> *Scenario 1 (web messaging)*
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    - The iframe src points to the authorize endpoint
>>>>>>>>>>    - The AS does not redirect, but responds with an HTML page
>>>>>>>>>>    containing JS code. This JS code uses postmessage to send a message
>>>>>>>>>>    containing the authorization code to the main application context.
>>>>>>>>>>    - The attacker receives this message and obtains the
>>>>>>>>>>    authorization code
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This approach is used by Auth0 and Apple. I have tested my attack
>>>>>>>>>> scenario against Auth0. Note that while this flow *does not use* the
>>>>>>>>>> redirect URI, it does validate the provided redirect URI. Additionally, the
>>>>>>>>>> admin needs to configure the AS to include the client’s origin in a list of
>>>>>>>>>> “Allowed Web Origins”.
>>>>>>>>>>
>>>>>>>>>> This is also the scenario I use in the demo I have linked to
>>>>>>>>>> above, so you can see it in action there.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *Scenario 2 (redirect)*
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    - The iframe src points to the authorize endpoint
>>>>>>>>>>    - The AS redirects the frame to the application’s callback
>>>>>>>>>>    with the authorization code as a query parameter
>>>>>>>>>>    - The attacker can monitor the iframe for a URL that contains
>>>>>>>>>>    the authorization code, stop the frame from loading (and redeeming the
>>>>>>>>>>    authorization code), and extract the code
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This approach is more universal, but just as vulnerable. The
>>>>>>>>>> scenario is exactly the same as in the demo linked to above, but the attack
>>>>>>>>>> code looks slightly different.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> To conclude, I have carefully argued my point of view on this
>>>>>>>>>> mailing list, in recorded videos, and in the sessions at the OAuth Security
>>>>>>>>>> Workshop last week. As far as I can tell, the experts in the community
>>>>>>>>>> acknowledge the dangers of browser-only apps (i.e., the attacker running a
>>>>>>>>>> silent flow)  and agree that the browser-based apps BCP should accurately
>>>>>>>>>> reflect this information. We’re currently working on updating the
>>>>>>>>>> specification (which will happen in multiple steps, so we ask for a bit of
>>>>>>>>>> patience).
>>>>>>>>>>
>>>>>>>>>> Unless you have anything new to add or any new issues to raise, I
>>>>>>>>>> respectfully opt to disengage from further discussion.
>>>>>>>>>>
>>>>>>>>>> Kind regards
>>>>>>>>>>
>>>>>>>>>> Philippe
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Yannick Majoros
>>>>>>>>> Valuya sprl
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Vennlig hilsen
>>>>>>
>>>>>> Steinar Noem
>>>>>> Partner Udelt AS
>>>>>> Systemutvikler
>>>>>>
>>>>>> | [e-mail] | [e-mail]  | [phone] | www.udelt.no |
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Yannick Majoros
>>>>> Valuya sprl
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>
>>>
>>> --
>>> Yannick Majoros
>>> Valuya sprl
>>>
>>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>