jiebi/CodeConvo huggingface dataset:
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,
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
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.
the frontend and the BFF do not require any preflights, so there's no additional overhead. <ins> 6.1.3.3.3. Some technology stacks and frameworks have built-in CRSF protection using anti-forgery cookies.  This mechanism relies on a session- specific secret that is stored in a cookie, which can only be read by the legitimate frontend running in the domain associated with the cookie.  The frontend is expected to read the cookie and insert its value into the request, typically by adding a custom request header. The backend verifies the value in the cookie to the value provided by the frontend to identify legitimate requests.  When implemented correctly for all state changing requests, this mechanism effectively mitigates CSRF. Note that this mechanism is not necessarily recommended over the CORS approach.  However, if a framework offers built-in support for this mechanism, it can serve as a low-effort alternative to protect against CSRF. </ins> 6.1.3.4. In the BFF pattern, all OAuth responsibilities have been moved to the
6.3.2.4.2. <ins> 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. 6.3.2.4.3. </ins> Browser-based applications MUST prevent CSRF attacks against their redirect URI.  This can be accomplished by any of the below:
Section 4.4 of oauth-security-topics provides additional details about mix-up attacks and the countermeasures mentioned above. <del> 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 hidden iframe-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. </del> 10. This document does not require any IANA actions.
The token-mediating backend pattern is more lightweight than the BFF pattern (See pattern-bff), since it does not require the proxying of <del> all requests to a resource server, which improves latency and significantly simplifies deployment.  From a security perspective, the token-mediating backend is less secure than a BFF, but still offers significant advantages over an OAuth client application running directly in the browser. </del> <ins> all requests and responses between the JavaScript application and the resource server.  From a security perspective, the token-mediating backend is less secure than a BFF, but still offers significant advantages over an OAuth client application running directly in the browser. </ins> If an attacker is able to execute malicious code within the JavaScript application, the application architecture is able to
The code in the browser initiates the authorization code flow with the PKCE extension (described in authorization_code_flow) (B) above, and obtains an access token via a POST request (C).  The JavaScript <del> app is then responsible for storing the access token (and optional refresh token) securely using appropriate browser APIs. </del> <ins> application is then responsible for storing the access token (and optional refresh token) as securely as possible using appropriate browser APIs.  As of the date of this publication there is no browser API that allows to store tokens in a completely secure way. </ins> When the JavaScript application in the browser wants to make a <del> request to the Resource Server, it can include the access token in the request (D) and make the request directly. </del> <ins> request to the Resource Server, it can interact with the Resource Server directly.  It includes the access token in the request (D) and receives the Resource Server's response (E). </ins> In this scenario, the Authorization Server and Resource Server MUST support the necessary CORS headers to enable the JavaScript code to
described in this document.  By restricting the protocol to only be executed on devices trusted by the authorization server, it prevents attackers from using arbitrary devices, or by mimicking devices to <del> initiate the protocol.  Trusted devices include devices that are pre- registered with the authorization server or are subject to device management policies.  Device management policies may enforce </del> <ins> initiate the protocol. Authorization Servers MAY use different mechanisms to establish which devices it trusts.  This includes limiting cross-device flows to specific device types such as intractive whiteboards or smart TVs, pre-registering devices with the authorization server or only allow cross-device flows on devices managed through device management systems.  Device management systems may enforce policies that govern </ins> patching, version updates, on-device anti-malware deployment, revocation status and device location amongst others.  Trusted <del> devices may have their identities rooted in hardware (e.g., a TPM or equivalent technology).  By only allowing trusted devices to initiate cross-device flows, it requires the attacker to have access to such a device and maintain access in a way that does not result in the device's trust status from being revoked. </del> <ins> devices MAY have their identities rooted in hardware (e.g., a TPM or equivalent technology). By only allowing trusted devices to initiate cross-device flows, it requires the attacker to have access to such a device and maintain access in a way that does not result in the device's trust status from being revoked. </ins> An attacker may still be able to obtain access to a trusted device and use it to initiate authorization requests, making it necessary to
credential.  In preserving the context, it should be clear to the user who invoked the flow, why it was invoked and what the consequence of completing the authorization, authentication or <del> credential presentation is.  The user experience should reinforce the </del> <ins> credential presentation is.  The user experience SHOULD reinforce the </ins> message that unless the user initiated the authorization request, or was expecting it, they should decline the request. <ins> This information MAY be communicated graphically or in a simple message (e.g., "It looks like you are trying to access your files on a digital whiteboard in your city center office.  Click here to grant access to your files.  If you are not trying to access your files, you should decline this request and notify the security department"). It SHOULD be clear to the user how to decline the request.  To avoid accidental authorization grants, the "decline" option SHOULD be the default option or given similar prominence in the user experience as the "grant" option. </ins> If the user uses an application on a mobile device to scan a QR code, the application MAY display information advising the user under which conditions they should expect to be asked to scan a QR code and under
trusted locations or on trusted websites hosted on a specific domain, and never in e-mail or other media and locations). <del> It SHOULD be clear to the user how to decline the request.  To avoid accidental authorization grants, the "decline" option SHOULD be the default option or given similar prominence in the user experience as the "grant" option. </del> The user experience MAY include information to further educate the user on cross-device consent phishing attacks and reinforce the conditions under which authorization grants may be requested. <del> This information may be communicated graphically or in a simple message (e.g., "It looks like you are trying to access your files on a digital whiteboard in your city center office.  Click here to grant access to your files.  If you are not trying to access your files, you should decline this request and notify the security department"). </del> Improvements to user experience on their own is unlikely to be sufficient and SHOULD be used in conjunction with other controls described in this document.
it in the CAD application, after which the CAD application displays the user's most recent designs. <ins> 2.4.9. A network administrator wants to access an adminstration portal used to configure network assets and deploy new applications.  When attempting to access the service, the network administrator receives a notification in an app on their mobile device, requesting them to confirm access to the portal.  The network administrator approves the request on their mobile phone and is granted access to the portal. </ins> 3. Attackers exploit cross-device flows by initiating an authorization
3.4.10. <ins> An attacker attempts to access an adminstration portal repeatedly, generating a stream of authorization requests to the network administrator.  The attempts are timed to occur while the administrator is asleep.  The administrator is woken by the incoming requests on their phone, and, in an attempt to stop the notifications, they accidentally approve access and the attacker gains access to the portal. 3.4.11. </ins> In all of the attack scenarios listed above, a user is misled or exploited.  For other attacks, where the user is willingly colluding with the attacker, the threat model, security implications and
3.4.5. <ins> An attacker obtains the contact information for a user and contacts them, pretending to be a representative of the user's financial institution.  The attacker informs the user that there were a number of fraudulent transactions against their account and asks them to review these transactions by approving or rejecting them.  The attacker then triggers a sequence of transactions.  The user receives an authorization request for each transaction and declines them as they do not recognize them.  The attacker then informs the user that they need to close the users account and transfer all the funds to a new account to prevent further fraudulent transactions.  The user receives another authorization request which they approve, or provide additional authorization information to the attacker which enables the attacker to complete their attack and defraud the user. 3.4.6. </ins> An attacker creates a message to all employees of a company, claiming to be from a trusted technology provider investigating a suspected security breach.  They ask employees to send them the QR code
phishing resistant authentication mechanism, which may in itself negate the need for a cross-device flow. <del> Starting with an authenticated flow does not prevent the attacks described in Example B5: Illicit Network Join [6] and Example B7: Illicit Session Transfer [7] and it is RECOMMENDED that additional mitigations described in this document is used if the cross-device flows are used in scenarios such as Example A5: Add a device to a network [8] and Example A7: Transfer a session [9]. </del> <ins> Authenticating on the Consumption Device before starting a cross- device flow does not prevent the attacks described in Example B5: Illicit Network Join [6] and Example B7: Illicit Session Transfer [7] and it is RECOMMENDED that additional mitigations described in this document is used if the cross-device flows are used in scenarios such as Example A5: Add a device to a network [8] and Example A7: Transfer a session [9]. </ins> 5.1.16.
a verifiable credential for authentication.  The attacker creates a phishing website which will in real time capture log-in QR Codes from the original website and present these to the user.  The attacker <del> tries to get the user to use the phishing website using an e-mail campaign etc.  The user scans the QR code on the phishing website, invokes their digital wallet and presents their credentials.  Once the credentials are presented, the original session from the attackers device is authorized with the user's credentials. </del> <ins> tries to get the user to use the phishing website by sending messages by e-mail or other messaging technologies.  The user scans the QR code on the phishing website, invokes their digital wallet and presents their credentials.  Once the credentials are presented, the original session from the attackers device is authorized with the user's credentials. </ins> 4.3.10.
3.3.1. An end-user sets up a new smart TV and wants to connect it to their <del> favorite streaming service.  The TV displays a QR code that the user scans with their mobile phone.  The user is redirected to the streaming service provider's web page and asked to enter their credentials to authorize the smart TV to access the streaming service.  The user enters their credentials and grants authorization, after which the streaming service is available on the smart TV. </del> <ins> favorite streaming service.  The streaming service displays a QR code on the TV that the user scans with their mobile phone.  The user is redirected to the streaming service provider's web page and asked to enter their credentials to authorize the smart TV to access the streaming service.  The user enters their credentials and grants authorization, after which the streaming service is available on the smart TV. </ins> 3.3.2.
4.3.1. An attacker obtains a smart TV and attempts to access an online <del> streaming service.  The smart TV obtains a QR code from the authorization server and displays it on screen.  The attacker copies the QR code and embeds it in an e-mail that is sent to a large number of recipients.  The e-mail contains a message stating that the </del> <ins> streaming service.  The smart TV obtains a QR code from the streaming service authorization server and displays it on screen.  The attacker copies the QR code and embeds it in an e-mail that is sent to a large number of recipients.  The e-mail contains a message stating that the </ins> streaming service wants to thank them for their loyal support and by scanning the QR code, they will be able to add a bonus device to their account for no charge.  One of the recipients open the e-mail
Examples of the user-transferred authorization data pattern include flows in which the Consumption Device requests the Authorization Server to send authorization data (e.g., a 6 digit authorization code <del> in a text message or e-mail) to the Authorization Device.  Once the Authorization Device receives the authorization data, the user enters it on the Consumption Device.  The Consumption Device sends the authorization data back to the Authorization Server for validation before gaining access to the user's resources.  The figure below shows an example of this flow. </del> <ins> in a text message, e-mail or mobile application) to the Authorization Device.  Once the Authorization Device receives the authorization data, the user enters it on the Consumption Device.  The Consumption Device sends the authorization data back to the Authorization Server for validation before gaining access to the user's resources.  The figure below shows an example of this flow. </ins> The Authorization Server may choose to authenticate the user before <del> sending the authorization data.  The authorization data may be delivered as a text message or through a mobile application. </del> <ins> sending the authorization data. </ins> 3.2.
6.2.3.5. FIDO2/WebAuthn SHOULD be used for cross-device authentication <del> scenarios whenever the devices are capable of doing so.  It MAY be used as an authentication method with the Authorization Code Grant </del> <ins> scenarios whenever the devices are capable of doing so and a suitable FIDO credential is not available on the consumption device.  It MAY be used as an authentication method with the Authorization Code Grant </ins> RFC6749 and PKCE RFC7663, to grant authorization to an Consumption Device (e.g., Smart TV or interactive whiteboard) using a mobile phone as the authenticating device.  This combination of FIDO2/
Protocol flows that span multiple end-user devices are in widespread use today.  These flows are often referred to as cross-device flows. A common example is a user that uses their mobile phone to scan a QR <del> code from their SmartTV, giving an app on the TV access to their </del> <ins> code from their smart TV, giving an app on the TV access to their </ins> video streaming service.  Besides QR codes, other mechanisms are often used such as PIN codes that the user has to enter on one of the devices, or push notifications to a mobile app that the user has to
3. Cross-device flows allow a user to start a flow on one device (e.g., <del> a SmartTV) and then transfer the session to continue it on a second </del> <ins> a smart TV) and then transfer the session to continue it on a second </ins> device (e.g., a mobile phone).  The second device may be used to access the service that was running on the first device, or to perform an action such as authenticating or granting authorization
4.1.1. A common action in cross-device flows is to present the user with a <del> QR code or a user code on the Consumption Device (e.g., Smart TV) </del> <ins> QR code or a user code on the Consumption Device (e.g., smart TV) </ins> which is then scanned or entered on the Authorization Device (the mobile phone).  When the user scans the code or copies the user code, they do so without any proof that the QR code or user code is being
Client Initiated Back-Channel Authentication (CIBA) CIBA: A standard developed in the OpenID Foundation that allows a device or service <del> (e.g., a personal computer, Smart TV, Kiosk) to request the OpenID </del> <ins> (e.g., a personal computer, smart TV, Kiosk) to request the OpenID </ins> Provider to initiate an authentication flow if it knows a valid identifier for the user.  The user completes the authentication flow using a second device (e.g., a mobile phone).  In this flow the user
FIDO credential is not available on the consumption device.  It MAY be used as an authentication method with the Authorization Code Grant RFC6749 and PKCE RFC7663, to grant authorization to an Consumption <del> Device (e.g., Smart TV or interactive whiteboard) using a mobile </del> <ins> Device (e.g., smart TV or interactive whiteboard) using a mobile </ins> phone as the authenticating device.  This combination of FIDO2/ WebAuthn and Authorization Code Flow with PKCE enables cross device authorization flows, without the risks posed by the Device