jiebi/CodeConvo huggingface dataset:
Code change:
Refactoring some architectural patterns: Single-Domain Browser-Based Apps (not using OAuth) Backend For Frontend (BFF) Proxy

Related discussion:
text: use a redirect mechanism to communicate between them. An additional concern with handling access tokens in a browser is <del> that as of the date of this publication, there is no secure storage mechanism where JavaScript code can keep the access token to be later used in an API request.  Using an OAuth flow results in the JavaScript code getting an access token, needing to store it somewhere, and then retrieve it to make an API request. Instead, a more secure design is to use an HTTP-only cookie between the JavaScript application and API so that the JavaScript code can't </del> <ins> that in case of successful XSS attack, tokens could be read and further used or transmitted by the injected code if no secure storage mechanism is in place. It could as such be considered to use an HTTP-only cookie between the JavaScript application and API so that the JavaScript code can't </ins> access the cookie value itself.  The "Secure" cookie attribute should be used to ensure the cookie is not included in unencrypted HTTP requests.  Additionally, the "SameSite" cookie attribute can be used <del> to counter CSRF attacks, but should not be considered the extent of the CSRF protection, as described in </del> <ins> to counter some CSRF attacks, but should not be considered the extent of the CSRF protection, as described in </ins> OAuth was originally created for third-party or federated access to APIs, so it may not be the best solution in a common-domain
Code change:
Refactoring some architectural patterns: Single-Domain Browser-Based Apps (not using OAuth) Backend For Frontend (BFF) Proxy

Related discussion:
text: and recovery at the OAuth server, rather than making it part of the application logic. <ins> Splitting of responsibilities between authenticating a user and serving resources </ins> Using OAuth for browser-based apps in a first-party same-domain <del> scenario provides these advantages, and can be accomplished by either of the two architectural patterns described below. </del> <ins> scenario provides these advantages, and can be accomplished by any of the architectural patterns described below. </ins> 6.2. In this architecture, commonly referred to as "backend for frontend" or "BFF", the JavaScript code is loaded from a dynamic Application <del> Server (A) that also has the ability to execute code itself.  This enables the ability to keep all of the steps involved in obtaining an access token outside of the JavaScript application. Note that this application backend is not the Resource Server, it is still considered part of the OAuth client and would be accessing data at a separate resource server. In this case, the Application Server initiates the OAuth flow itself, by redirecting the browser to the authorization endpoint (B).  When the user is redirected back, the browser delivers the authorization code to the application server (C), where it can then exchange it for an access token at the token endpoint (D) using its client secret. The application server then keeps the access token and refresh token stored internally, and creates a separate session with the browser- based app via a traditional browser cookie (E). </del> <ins> Server (A) that has the ability to execute code and handle the full authentication flow itself.  This enables the ability to keep the call to actually get an access token outside the JavaScript application. Note that this BFF is not the Resource Server, it is the OAuth client and would be accessing data at a separate resource server. In this case, the BFF initiates the OAuth flow itself, by redirecting the browser to the authorization endpoint (B).  When the user is redirected back, the browser delivers the authorization code to the application server (C), where it can then exchange it for an access token at the token endpoint (D) using its client secret and PKCE code verifier.  The application server then keeps the access token and refresh token stored internally, and creates a separate session with the browser-based app via a traditional browser cookie (E). </ins> When the JavaScript application in the browser wants to make a request to the Resource Server, it instead makes the request to the
Code change:
Refactoring some architectural patterns: Single-Domain Browser-Based Apps (not using OAuth) Backend For Frontend (BFF) Proxy

Related discussion:
text: In this scenario, the connection between the browser and Application Server SHOULD be a session cookie provided by the Application Server. <ins> 6.2.1. </ins> Security of the connection between code running in the browser and this Application Server is assumed to utilize browser-level protection mechanisms.  Details are out of scope of this document,
Code change:
Refactoring some architectural patterns: Single-Domain Browser-Based Apps (not using OAuth) Backend For Frontend (BFF) Proxy

Related discussion:
text: and "Secure" cookie to authenticate the session between the browser and Application Server. <ins> Additionally, cookies MUST be protected from leakage by other means, such as logs. This architecture protects against tokens leakage from the browser, but creates a CSRF attack vector: once the user is authenticated, the BFF proxy will automatically add tokens to calls to the resource server. </ins> 6.3. In this architecture, the JavaScript code is first loaded from a
Code change:
reworked some architectural patterns: Javascript applications accessing resource servers directly (js = oauth client)

Related discussion:
text: In this architecture, the JavaScript code is first loaded from a static web host into the browser (A), and the application then runs in the browser.  This application is considered a public client, <del> since there is no way to issue it a client secret and there is no other secure client authentication mechanism available in the browser. </del> <ins> since there is no way to issue it a client secret and authentication is handled by the application, not by the browser. </ins> The code in the browser initiates the Authorization Code flow with the PKCE extension (described in authorization_code_flow) (B) above, <del> and obtains an access token via a POST request (C).  The JavaScript application is then responsible for storing the access token (and </del> <ins> and obtains an access token via a POST request (C). The application is then responsible for storing the access token (and </ins> optional refresh token) as securely as possible using appropriate <del> browser APIs.  As of the date of this publication there is no browser API that allows to store tokens in a completely secure way. </del> <ins> browser APIs. </ins> When the JavaScript application in the browser wants to make a request to the Resource Server, it can interact with the Resource
Code change:
reworked some architectural patterns: Javascript applications accessing resource servers directly (js = oauth client)

Related discussion:
text: In this scenario, the Authorization Server and Resource Server MUST support the necessary CORS headers to enable the JavaScript code to <del> make this POST request from the domain on which the script is </del> <ins> make these POST requests from the domain on which the script is </ins> executing.  (See cors for additional details.) 7.
Code change:
reworked some architectural patterns: Javascript applications accessing resource servers directly (js = oauth client)

Related discussion:
text: refresh token to obtain new access tokens potentially without being detectable by the authorization server. <del> Browser-based applications provide an attacker with several opportunities by which a refresh token can be leaked, just as with access tokens.  As such, these applications are considered a higher risk for handling refresh tokens. </del> <ins> Javascript-accessible storage mechanisms like _Local Storage_ provide an attacker with several opportunities by which a refresh token can be leaked, just as with access tokens.  As such, these mechanisms are considered a higher risk for handling refresh tokens. </ins> Authorization servers may choose whether or not to issue refresh tokens to browser-based applications. oauth-security-topics describes
Code change:
This looks great. I'm going to merge this and make a few minor tweaks to it.

Related discussion:
text: having refresh tokens at all to avoid the risk of giving prolonged access to the attacker. <ins> 6.3.2. In this scenario, a Service Worker [1] is responsible for obtaining tokens from the authorization server and passing them to the resource API. Service workers are inherently safe from XSS, because the browser APIs allowing to register one take an origin-constrained URL.  They can thus be used as a safe store for tokens. In this architecture, a service worker intercepts calls from the frontend to the resource server.  As such, it completely isolates calls to the authorization server from XSS attack surface, as all tokens and PKCE secrets are safely kept there without any access from other JavaScript contexts.  The service worker is then solely responsible for adding authentication headers to calls to the resource server. 6.3.2.1. The service worker MUST initiate the OAuth 2.0 Authorization Code grant with PKCE itself. The service worker MUST intercept the authorization code when the _authorization server_ redirects to the application.  This makes this architecture completely safe from token or session leaks in case of XSS. The service worker implementation MUST then initiate the token request itself. The service worker MUST not transmit tokens, authorization codes or PKCE secrets (e.g. code verifier) to the frontend application. The service worker MUST block /token or /authorize calls initiating from the frontend application in order to avoid any front-end side-channel for getting credentials: the only way of starting the authorization flow is through the service worker. This protects against re-authorization from XSS-injected code. </ins> 7. Browser-based applications that are public clients and use the
Code change:
I moved the considerations about XSS to a general section: all architectures are concerned. I added some words about bypassing the Service Worker: this would need a very broad successful XSS, with a much broader attack surface than what is typically the case. This can be mitigated by making sure that registering the service worker is the very first thing happening. There is also no API for unregistering a SW, so it can't be removed after the fact.
I haven't dug too deep yet but isn't this an API to unregister a service worker? URL
Indeed, this mitigation won't work. I oversaw the registration itself and focused on URL . I'll rework this and focus on what can be guaranteed by specs.
I removed the part about service workers for now. I'll see if I can further improve it in another PR.

Related discussion:
text: 6.1. <ins> For all known architectures, all precautions MUST be taken to prevent XSS attacks.  In general, cross-site scripting (XSS) attacks are a huge risk, and can lead to full compromise of the application. 6.2. </ins> For simple system architectures, such as when the JavaScript application is served from a domain that can share cookies with the domain of the API (resource server) and the authorization server,
Code change:
I moved the considerations about XSS to a general section: all architectures are concerned. I added some words about bypassing the Service Worker: this would need a very broad successful XSS, with a much broader attack surface than what is typically the case. This can be mitigated by making sure that registering the service worker is the very first thing happening. There is also no API for unregistering a SW, so it can't be removed after the fact.
I haven't dug too deep yet but isn't this an API to unregister a service worker? URL
Indeed, this mitigation won't work. I oversaw the registration itself and focused on URL . I'll rework this and focus on what can be guaranteed by specs.
I removed the part about service workers for now. I'll see if I can further improve it in another PR.

Related discussion:
text: scenario provides these advantages, and can be accomplished by any of the architectural patterns described below. <del> 6.2. </del> <ins> 6.3. </ins> In this architecture, commonly referred to as "backend for frontend" or "BFF", the JavaScript code is loaded from a dynamic Application
Code change:
I moved the considerations about XSS to a general section: all architectures are concerned. I added some words about bypassing the Service Worker: this would need a very broad successful XSS, with a much broader attack surface than what is typically the case. This can be mitigated by making sure that registering the service worker is the very first thing happening. There is also no API for unregistering a SW, so it can't be removed after the fact.
I haven't dug too deep yet but isn't this an API to unregister a service worker? URL
Indeed, this mitigation won't work. I oversaw the registration itself and focused on URL . I'll rework this and focus on what can be guaranteed by specs.
I removed the part about service workers for now. I'll see if I can further improve it in another PR.

Related discussion:
text: In this scenario, the connection between the browser and Application Server SHOULD be a session cookie provided by the Application Server. <del> 6.2.1. </del> <ins> 6.3.1. </ins> Security of the connection between code running in the browser and this Application Server is assumed to utilize browser-level
Code change:
I moved the considerations about XSS to a general section: all architectures are concerned. I added some words about bypassing the Service Worker: this would need a very broad successful XSS, with a much broader attack surface than what is typically the case. This can be mitigated by making sure that registering the service worker is the very first thing happening. There is also no API for unregistering a SW, so it can't be removed after the fact.
I haven't dug too deep yet but isn't this an API to unregister a service worker? URL
Indeed, this mitigation won't work. I oversaw the registration itself and focused on URL . I'll rework this and focus on what can be guaranteed by specs.
I removed the part about service workers for now. I'll see if I can further improve it in another PR.

Related discussion:
text: BFF proxy will automatically add tokens to calls to the resource server. <del> 6.3. </del> <ins> 6.4. </ins> In this architecture, the JavaScript code is first loaded from a static web host into the browser (A), and the application then runs
Code change:
I moved the considerations about XSS to a general section: all architectures are concerned. I added some words about bypassing the Service Worker: this would need a very broad successful XSS, with a much broader attack surface than what is typically the case. This can be mitigated by making sure that registering the service worker is the very first thing happening. There is also no API for unregistering a SW, so it can't be removed after the fact.
I haven't dug too deep yet but isn't this an API to unregister a service worker? URL
Indeed, this mitigation won't work. I oversaw the registration itself and focused on URL . I'll rework this and focus on what can be guaranteed by specs.
I removed the part about service workers for now. I'll see if I can further improve it in another PR.

Related discussion:
text: make these POST requests from the domain on which the script is executing.  (See cors for additional details.) <del> All precautions MUST be taken to prevent XSS attacks. </del> <ins> Besides the general risks of XSS, if tokens are stored or handled by the browser, XSS poses an additional risk of token exfiltration.  In this architecture, the JavaScript application is storing the access token so that it can make requests directly to the resource server. There are two primary methods by which the application can store the token, with different security considerations of each. </ins> <del> In general, cross-site scripting (XSS) attacks are a huge risk, and can lead to full compromise of the application.  If tokens are ever stored or handled by the browser, XSS poses an additional risk of token exfiltration.  In this architecture, the JavaScript application is storing the access token so that it can make requests directly to the resource server.  There are two primary methods by which the application can store the token, with slightly different security considerations of each. 6.3.1. </del> <ins> 6.4.1. </ins> If the JavaScript in the DOM will be making requests directly to the <del> resource server, it will need to store the tokens somewhere accessible to the DOM.  In the case of a successful XSS attack, the injected code will have full access to the stored tokens and can exfiltrate them to the attacker. </del> <ins> resource server, the simplest mechanism is to store the tokens somewhere accessible to the DOM.  In the case of a successful XSS attack, the injected code will have full access to the stored tokens and can exfiltrate them to the attacker. </ins> <del> 6.3.2. </del> <ins> 6.4.2. </ins> In this scenario, a Service Worker [1] is responsible for obtaining tokens from the authorization server and making requests to the
Code change:
I moved the considerations about XSS to a general section: all architectures are concerned. I added some words about bypassing the Service Worker: this would need a very broad successful XSS, with a much broader attack surface than what is typically the case. This can be mitigated by making sure that registering the service worker is the very first thing happening. There is also no API for unregistering a SW, so it can't be removed after the fact.
I haven't dug too deep yet but isn't this an API to unregister a service worker? URL
Indeed, this mitigation won't work. I oversaw the registration itself and focused on URL . I'll rework this and focus on what can be guaranteed by specs.
I removed the part about service workers for now. I'll see if I can further improve it in another PR.

Related discussion:
text: solely responsible for adding the token in the authorization header to calls to the resource server. <del> 6.3.2.1. </del> <ins> 6.4.2.1. </ins> The service worker MUST initiate the OAuth 2.0 Authorization Code grant with PKCE itself.
Code change:
I moved the considerations about XSS to a general section: all architectures are concerned. I added some words about bypassing the Service Worker: this would need a very broad successful XSS, with a much broader attack surface than what is typically the case. This can be mitigated by making sure that registering the service worker is the very first thing happening. There is also no API for unregistering a SW, so it can't be removed after the fact.
I haven't dug too deep yet but isn't this an API to unregister a service worker? URL
Indeed, this mitigation won't work. I oversaw the registration itself and focused on URL . I'll rework this and focus on what can be guaranteed by specs.
I removed the part about service workers for now. I'll see if I can further improve it in another PR.

Related discussion:
text: worker.  This protects against re-authorization from XSS-injected code. <del> 6.3.2.2. </del> <ins> 6.4.2.2. </ins> A successful XSS attack on an application using this Service Worker pattern would be unable to exfiltrate existing tokens stored by the
Code change:
I moved the considerations about XSS to a general section: all architectures are concerned. I added some words about bypassing the Service Worker: this would need a very broad successful XSS, with a much broader attack surface than what is typically the case. This can be mitigated by making sure that registering the service worker is the very first thing happening. There is also no API for unregistering a SW, so it can't be removed after the fact.
I haven't dug too deep yet but isn't this an API to unregister a service worker? URL
Indeed, this mitigation won't work. I oversaw the registration itself and focused on URL . I'll rework this and focus on what can be guaranteed by specs.
I removed the part about service workers for now. I'll see if I can further improve it in another PR.

Related discussion:
text: However, an XSS attack would still result in the attacker being able to initiate a new OAuth flow, and/or unregister the Service Worker. <del> 6.3.3. </del> <ins> 6.4.3. </ins> To limit the risk of token exfiltration:
Code change:
As discussed on the OSW, this PR adds a small section with security considerations on the use of (a.k.a. "web messaging") to this draft. It makes reference to , which already discusses the security implications of in-browser communication flows in detail. Since (silent) iframe flows and popup flows are especially used in browser-based apps, we think that it makes sense to include security considerations of their in-browser communication into this draft. Please let us know what you think about this. We appreciate any feedback.
Sounds good to me, thanks!

Related discussion:
text: Section 4.4 of oauth-security-topics provides additional details about mix-up attacks and the countermeasures mentioned above. <ins> 9.4. In browser-based apps, it is common to execute the OAuth flow in a secondary window, such as a popup or iframe, instead of redirecting the primary window.  In these flows, the browser-based app holds control of the primary window, for instance, to avoid page refreshes or run silent frame-based flows. If the browser-based app and the authorization server are invoked in different frames, they have to use in-browser communication techniques like the postMessage API (a.k.a.  WebMessaging) instead of top-level redirections.  To guarantee confidentiality and authenticity of messages, both the initiator origin and receiver origin of a postMessage MUST be verified using the mechanisms inherently provided by the postMessage API (Section 9.3.2 in WebMessaging). Section 4.18. of oauth-security-topics provides additional details about the security of in-browser communication flows and the countermeasures that browser-based apps and authorization servers MUST apply to defend against these attacks. </ins> 10. This document does not require any IANA actions.