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

[Aaron Parecki <[e-mail]>]

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