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

[Dick Hardt <[e-mail]>]

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
>