jiebi/TextFlow huggingface dataset:
Original 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>  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>  OAuth was originally created for third-party or federated access to APIs, so it may not be the best solution in a common-domain

Reviewer comments:
Refactoring some architectural patterns: Single-Domain Browser-Based Apps (not using OAuth) Backend For Frontend (BFF) Proxy

Revised text:
use a redirect mechanism to communicate between them. An additional concern with handling access tokens in a browser is  <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  <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
Original text:
and recovery at the OAuth server, rather than making it part of the application logic.  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>  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>  When the JavaScript application in the browser wants to make a request to the Resource Server, it instead makes the request to the

Reviewer comments:
Refactoring some architectural patterns: Single-Domain Browser-Based Apps (not using OAuth) Backend For Frontend (BFF) Proxy

Revised 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  <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  <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
Original text:
In this scenario, the connection between the browser and Application Server SHOULD be a session cookie provided by the Application Server.  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,

Reviewer comments:
Refactoring some architectural patterns: Single-Domain Browser-Based Apps (not using OAuth) Backend For Frontend (BFF) Proxy

Revised 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,
Original text:
and "Secure" cookie to authenticate the session between the browser and Application Server.  6.3. In this architecture, the JavaScript code is first loaded from a

Reviewer comments:
Refactoring some architectural patterns: Single-Domain Browser-Based Apps (not using OAuth) Backend For Frontend (BFF) Proxy

Revised 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
Original 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>  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>  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>  When the JavaScript application in the browser wants to make a request to the Resource Server, it can interact with the Resource

Reviewer comments:
reworked some architectural patterns: Javascript applications accessing resource servers directly (js = oauth client)

Revised 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,  <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,  <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  <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
Original 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>  executing.  (See cors for additional details.) 7.

Reviewer comments:
reworked some architectural patterns: Javascript applications accessing resource servers directly (js = oauth client)

Revised text:
In this scenario, the Authorization Server and Resource Server MUST support the necessary CORS headers to enable the JavaScript code to  <ins> make these POST requests from the domain on which the script is </ins> executing.  (See cors for additional details.) 7.
Original 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>  Authorization servers may choose whether or not to issue refresh tokens to browser-based applications. oauth-security-topics describes

Reviewer comments:
reworked some architectural patterns: Javascript applications accessing resource servers directly (js = oauth client)

Revised text:
refresh token to obtain new access tokens potentially without being detectable by the authorization server.  <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
Original text:
having refresh tokens at all to avoid the risk of giving prolonged access to the attacker.  7. Browser-based applications that are public clients and use the

Reviewer comments:
This looks great. I'm going to merge this and make a few minor tweaks to it.

Revised 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
Original text:
10. This document does not require any IANA actions. 

Reviewer comments:
This looks great. I'm going to merge this and make a few minor tweaks to it.

Revised text:
10. This document does not require any IANA actions. <ins> 11.  References 11.1.  URIs [1] https://developer.mozilla.org/en-US/docs/Web/API/ Service_Worker_API </ins>
Original text:
6.1.  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,

Reviewer comments:
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.

Revised 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,
Original text:
scenario provides these advantages, and can be accomplished by any of the architectural patterns described below. <del> 6.2. </del>  In this architecture, commonly referred to as "backend for frontend" or "BFF", the JavaScript code is loaded from a dynamic Application

Reviewer comments:
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.

Revised text:
scenario provides these advantages, and can be accomplished by any of the architectural patterns described below.  <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
Original 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>  Security of the connection between code running in the browser and this Application Server is assumed to utilize browser-level

Reviewer comments:
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.

Revised text:
In this scenario, the connection between the browser and Application Server SHOULD be a session cookie provided by the Application Server.  <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
Original text:
BFF proxy will automatically add tokens to calls to the resource server. <del> 6.3. </del>  In this architecture, the JavaScript code is first loaded from a static web host into the browser (A), and the application then runs

Reviewer comments:
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.

Revised text:
BFF proxy will automatically add tokens to calls to the resource server.  <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
Original 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>  <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>  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>  <del> 6.3.2. </del>  In this scenario, a Service Worker [1] is responsible for obtaining tokens from the authorization server and making requests to the

Reviewer comments:
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.

Revised text:
make these POST requests from the domain on which the script is executing.  (See cors for additional details.)  <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>  <ins> 6.4.1. </ins> If the JavaScript in the DOM will be making requests directly to the  <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>  <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
Original text:
solely responsible for adding the token in the authorization header to calls to the resource server. <del> 6.3.2.1. </del>  The service worker MUST initiate the OAuth 2.0 Authorization Code grant with PKCE itself.

Reviewer comments:
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.

Revised text:
solely responsible for adding the token in the authorization header to calls to the resource server.  <ins> 6.4.2.1. </ins> The service worker MUST initiate the OAuth 2.0 Authorization Code grant with PKCE itself.
Original text:
worker.  This protects against re-authorization from XSS-injected code. <del> 6.3.2.2. </del>  A successful XSS attack on an application using this Service Worker pattern would be unable to exfiltrate existing tokens stored by the

Reviewer comments:
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.

Revised text:
worker.  This protects against re-authorization from XSS-injected code.  <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