jiebi/CodeConvo huggingface dataset:
Server MUST reject the request (do we need to define a specific error code for that?). <del> 9.4.2. </del> <ins> 9.5.2. </ins> It may be possible to use other proof of possession mechanisms to sender constrain access and refresh tokens.  Defining these mechanisms are out of scope for this specification. <del> 9.4.3. </del> <ins> 9.5.3. </ins> PoP binding of device session parameter <del> 9.5. </del> <ins> 9.6. </ins> When there is more than one 1st-party native applications supported by the AS, then it is important to consider a number of additional risks.  These risks fall into two main categories: Experience Risk and Technical Risk which are described below. <del> 9.5.1. </del> <ins> 9.6.1. </ins> Any time a user is asked to provide the authentication credentials in user experiences that differ, it has the effect of increasing the likelihood that the user will fall prey to a phishing attack because they are used to entering credentials in different looking <del> experiences.  When multiple native applications are support, the </del> <ins> experiences.  When multiple native applications are supported, the </ins> implementation MUST ensure the native experience is identical across all the 1st party native applications.
will not complete the authentication experience for the 1st party native application. <del> 9.5.2. </del> <ins> 9.6.2. </ins> In addition to the experience risks, multiple implementations in 1st party native applications increases the risk of an incorrect implementation as well as increasing the attack surface as each implementation may expose it's own weaknesses. <del> 9.5.3. </del> <ins> 9.6.3. </ins> To address these risk, when multiple 1st party native applications must be supported, and other methods such as OpenID.Native-SSO are
5.2.2. <ins> In the case where the authorization server wishes to interact with the user directly, it can return the "redirect" response.  The authorization server may choose to interact directly with the user based on a risk assesment, the introduction of a new authentication method not supported in the application, or to handle an exception flow like account recovery.  In this case the client is expected to initiate a traditional OAuth Authorization Code flow with PKCE according to RFC6749 and RFC7636. 5.2.3. </ins> If the request contains invalid parameters or incorrect data, the authorization server responds with an HTTP 400 (Bad Request) status code (unless specified otherwise) and includes the following
5.2. The authorization server determines whether the information provided <del> up to this point is sufficient to issue an authorization code, and responds with an authorization code or an error message. </del> <ins> up to this point is sufficient to issue an authorization code, and if so responds with an authorization code.  If the information is not sufficient for issuing an authorization code, then the authorization server MUST respond with an error response. </ins> 5.2.1.
code (unless specified otherwise) and includes the following parameters with the response: <ins> This specification requires the authorization server to define new error codes that relate to the actions the client must take in order to properly authenticate the user.  These new error codes are specific to the authorization server's implementation of this specification and are intentionally left out of scope. </ins> The parameters are included in the content of the HTTP response using the "application/json" media type as defined by RFC7159.  The parameters are serialized into a JSON structure by adding each
9.1. <ins> First-party applications are applications that the user recognizes as belonging to the same brand as the authorization server.  For example, a bank publishing their own mobile application. </ins> Because this specification enables a client application to interact directly with the end user, and the application handles sending any information collected from the user to the authorization server, it is expected to be used only for first-party applications when the authorization server also has a high degree of trust of the client. <del> First-party applications are applications that the user recognizes as belonging to the same brand as the authorization server.  For example, a bank publishing their own mobile application. </del> <ins> This specification is not prescriptive on how the Authorization Server establishes it's trust in the first-partyness of the application.  For mobile platforms, most support some mechanism for application attestation that can be used to identify the entity that created/signed/uploaded the app to the app store.  App attestation can be combined with other mechanisms like Dynamic Client Registration RFC7591 to enable strong client authentication in addition to client verification (first-partyness).  The exact steps required are out of scope for this specification.  Note that applications running inside a browser (e.g.  Single Page Apps) context it is much more difficult to verify the first-partyness of the client.  Please see single-page-apps for additional details. </ins> 9.2.
applications and to ensure the user experience is identical for all first-party apps. <ins> 9.7. Single Page Applications (SPA) run inside the context of a browser instance.  Due to the inability to securely attest to the first- partyness of a browser based application, it is NOT RECOMMENDED to use this specification in a browser-based application. </ins> 10. IANA has (TBD) registered the following values in the IANA "OAuth
server. The "auth_session" value is completely opaque to the client, and as <del> such the AS MUST adequately protect the value from inspection by the client, for example by using a random string or using a JWE if the AS is not maintaining state on the backend. </del> <ins> such the authorization server MUST adequately protect the value from inspection by the client, for example by using a random string or using a JWE if the authorization server is not maintaining state on the backend. </ins> If the client has an "auth_session", the client MUST include it in future requests to the authorization challenge endpoint.  The client
values are static, and MUST be prepared to update the stored "auth_session" value if one is received in a response. <ins> To mitigate the risk of session hijacking, the 'auth_session' MUST be bound to the device, and the authorization server MUST reject an 'auth_session' if it is presented from a different device than the one it was bound to. </ins> See auth-session-security for additional security considerations. 6.
9.6.1. If the client and authorization server are using DPoP binding of <del> access tokens and/or authorization codes, then they SHOULD also require DPoP binding of the "auth_session" value as well. </del> <ins> access tokens and/or authorization codes, then the "auth_session" value SHOULD be protected by the DPoP binding as well.  The authorization server SHOULD bind the "auth_session" value to the DPoP public key.  If the authorization server is binding the "auth_session" value to the DPoP public key, it MUST check that the same DPoP public key is being used and MUST verify the DPoP proof to ensure the client controls the corresponding private key whenever the client includes the "auth_session" in an Authorization Challenge Request as described in challenge-request. </ins> DPoP binding of the "auth_session" value ensures that the context referenced by the "auth_session" cannot be stolen and reused by another device. <del> This specification defines an additional claim in the DPoP Proof JWT Syntax defined in Section 4.2 of RFC9449: </del> 9.6.2. This specification makes no requirements or assumptions on the
end protection that DPoP provides, so DPoP Authorization Code binding SHOULD be used. <del> To bind the authorization code using the Authorization Challenge Endpoint, the JWK Thumbprint of the DPoP key MUST be communicated to the Authorization Server by including the "dpop_jkt" parameter defined in section 10 of RFC9449 alongside other authorization request parameters in the POST body of the first Authorization Challenge Request.  If it is included in subsequent Authorization Challenge Requests, the value of this parameter must be the same as in the initial request.  If the JWK Thumbprint in the "dpop_jkt" differ at any point, the Authorization Server MUST reject the request.  If the "dpop_jkt" parameter is not included in the first request, but added in subsequent requests, the Authorization Server MUST reject the request (do we need to define a specific error code for that?). </del> <ins> The mechanism for Authorization Code binding with DPoP is similar as that defined for Pushed Authorization Requests (PARs) in Section 10.1 of RFC9449.  In order to bind the Authorization Code with DPoP, the client MUST add the DPoP header to the Authorization Challenge Request.  The authorization server MUST check the DPoP proof JWT that was included in the DPoP header as defined in Section 4.3 of RFC9449. The authorization server MUST ensure that the same key is used in all subsequent Authorization Challenge Requests, or in the eventual token request.  The authorization server MUST reject subsequent Authorization Challenge Requests, or the eventual token request, unless a DPoP proof for the same key presented in the original Authorization Challenge Request is provided. The above mechanism simplifies the implementation of the client, as it can attach the DPoP header to all requests to the authorization server regardless of the type of request.  This mechanism provides a stronger binding than using the "dpop_jkt" parameter, as the DPoP header contains a proof of possession of the private key. </ins> 9.5.2.
deployed in a tightly coupled environment since it is only applicable to first-party applications. <ins> 1.3. It is important to consider the user experience implications of different authentication challenges as well as the device with which the user is attempting to authorize.  For example, requesting a user to enter a password on a limited input device (e.g.  TV) creates a lot of user friction while also exposing the user's password to anyone else in the room.  On the other hand, using a challenge method that involves say a fingerprint reader on the TV remote allowing for a FIDO2 passkey authentication would be a good experience.  The Authorization Server should consider the user's device when presenting authentication challenges and developers should consider whether the device implementing this specification can provide a good experience for the user.  If the combination of user device and authentiation challenge methods creates a lot of friction or security risk, consider using a specification like OAuth 2.0 Device Authorization Grant RFC8628.  If selecting OAuth 2.0 Device Authorization Grant RFC8628 which uses a cross-device authorization mechanism, please incorporate the security best practices identified in Cross-Device Flows: Security Best Current Practice I-D.ietf-oauth- cross-device-security. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
There are two ways using this specification increases the risk of phishing. <del> With this specification, the client interacts directly with the end user, collecting information provided by the user and sending it to the authorization server.  If an attacker impersonates the client and successfully tricks a user into using it, they may not realize they are giving their credentials to the malicious application. In a traditional OAuth deployment using the redirect-based authorization code flow, the user will only ever enter their credentials at the authorization server, and it is straightforward to explain to avoid entering credentials in other "fake" websites.  By introducing a new place the user is expected to enter their credentials using this specification, it is more complicated to teach users how to recognize other fake login prompts that might be attempting to steal their credentials. </del> <ins> Malicious application: With this specification, the client interacts directly with the end user, collecting information provided by the user and sending it to the authorization server. If an attacker impersonates the client and successfully tricks a user into using it, they may not realize they are giving their credentials to the malicious application. User education: In a traditional OAuth deployment using the redirect-based authorization code flow, the user will only ever enter their credentials at the authorization server, and it is straightforward to explain to avoid entering credentials in other "fake" websites.  By introducing a new place the user is expected to enter their credentials using this specification, it is more complicated to teach users how to recognize other fake login prompts that might be attempting to steal their credentials. </ins> Because of these risks, the authorization server MAY decide to require that the user go through a redirect-based flow at any stage
defined in Section 5.1 with the additional parameter "auth_session", defined in auth-session. <del> The response MAY include an "auth_session" parameter which the client is expected to include on a subsequent request to the authorization challenge endpoint.  The "auth_session" parameter MAY also be included even if the authorization code was obtained through a traditional OAuth authorization code flow rather than the flow defined by this specification. </del> An example successful token response is below: <ins> The response MAY include an "auth_session" parameter which the client is expected to include on any subsequent requests to the authorization challenge endpoint, as described in auth-session.  The "auth_session" parameter MAY also be included even if the authorization code was obtained through a traditional OAuth authorization code flow rather than the flow defined by this specification. Including the "auth_session" parameter in the token response enables flows such as step-up authentication RFC9470, so that the authorization server can restore the context of a previous session and prompt only for the needed step-up factors.  See step-up-sms- example for an example application. </ins> 6.2. Upon any request to the token endpoint, including a request with a
If the client and authorization server are using DPoP binding of access tokens and/or authorization codes, then the "auth_session" <del> value SHOULD be protected by the DPoP binding as well.  The authorization server SHOULD bind the "auth_session" value to the DPoP public key.  If the authorization server is binding the "auth_session" value to the DPoP public key, it MUST check that the same DPoP public key is being used and MUST verify the DPoP proof to ensure the client controls the corresponding private key whenever the client includes the "auth_session" in an Authorization Challenge Request as described in challenge-request. </del> <ins> value SHOULD be protected as well.  The authorization server SHOULD associate the "auth_session" value with the DPoP public key.  This removes the need for the authorization server to include additional claims in the DPoP proof, while still benefitting from the assurance that the client presenting the proof has control over the DPoP key. To associate the "auth_session" value with the DPoP public key, the authorization server: MUST check that the same DPoP public key is being used when the client presents the DPoP proof. MUST verify the DPoP proof to ensure the client controls the corresponding private key whenever the client includes the "auth_session" in an Authorization Challenge Request as described in challenge-request. </ins> DPoP binding of the "auth_session" value ensures that the context referenced by the "auth_session" cannot be stolen and reused by
2.1. <ins> 2.1.1. A US state official in State A needs to access the database of State B to retrieve information about a customer who is a citizen of State B.  The official first gains access to the State A gateway by logging in and authenticating to their local front-end system.  The gateway then passes the official's request and identity to a central information sharing system that all states use to share data. Finally, the central system obtains credentials to access the State B gateway and routes the request from the official, along with the officials identity, to the State B gateway to access the customer's information in the State B database. 2.1.2. A home devices company provides a "Camera API" to enable access to home cameras.  Partner companies use this Camera API to integrate the camera feeds into their security dashboards.  Using 2-legged OAuth between the partner and the Camera API, a partner can request the feed from a home camera to be displayed in their dashboard.  The user has an account with the camera provider.  The user may be logged in to view the partner provided dashboard, or they may authorize emergency access to the camera.  The home devices company must be able to independently verify that the request originated and was authorized by a user who is authorized to view the feed of the requested home camera. 2.1.3. A user attempts to access a service that is implemented as a number of on-prem and cloud-based microservices.  Both the on-premise and cloud-based services are segmented by multiple trust boundaries that span one or more on-premise or cloud service environments.  Every microservice can apply an authorization policy that takes the context of the original user, as well as intermediary microservices into account, irrespective of where the microservices are running and even when a microservice in one trust domain calls another service in another trust domain. 2.1.4. A client requests a report from a "local" resource that incorporates data from one or more associated sources.  Each source is in a separate trust domain.  Trust domains have a federated identity framework (e.g.  PKI) and authorization framework, but may have varied and asymmetric specific trust relationships (e.g. transitive trust is not guaranteed).  Trust relationships are established between authorization servers in each trust domain, and exercised through messages passed between the authorization servers that assert identity and authorization claims.  The identity of requesters is chained throughout, but authorization claims are limited to what is necessary to each request. 2.2. </ins> The Identity Chaining flow outlined below describes how these specification are used and work together.  Two examples in the suffix give more concrete examples.  One where a resource server acts as the
(F) The client now possesses an access token to access the protected resource in Domain B. <del> 2.2. </del> <ins> 2.3. </ins> This specification does not define authorization server discovery.  A client MAY contact the resource and leverage the WWW-Authentication response (see section 3 of RFC6750), maintain a static mapping or use other means to identify the authorization server. <del> 2.3. </del> <ins> 2.4. </ins> Once the authorization server is identified the client performs token exchange as defined in RFC8693 with its own authorization server in order to obtain an authorization grant as specified in section 1.3 of RFC6749. <del> 2.3.1. </del> <ins> 2.4.1. </ins> The parameters described in section 2.1 of RFC8693 apply here with the following restrictions: <del> 2.3.2. </del> <ins> 2.4.2. </ins> An authorization server SHOULD deny the request on an unknown resource or audience.  In cases where federation to any
only one audience is used to prevent Authorization Server B to abuse and present the token to Authorization Server C. <del> 2.3.6. </del> <ins> 2.4.6. </ins> The example belows shows the message invoked by the client in trust domain A to perform token exchange with the authorization server in domain A (https://a.org/auth) to receive an authorization grant for the authorization server in trust domain B (https://b.org/auth). <del> 2.4. </del> <ins> 2.5. </ins> The client uses the received authorization grant from steps B and C as an asseration towards authorization server of domain B. <del> 2.4.1. </del> <ins> 2.5.1. </ins> If the authorization grant is in the form of a JWT bearer token, the client SHOULD use the "JSON Web Token (JWT) Profile for OAuth 2.0
The specifics (such as the format) of returned access token is not part of this specification. <del> 2.4.4. </del> <ins> 2.5.4. </ins> The authorization server responds with an access token as described in section 5.1 of RFC6749. <del> 2.4.5. </del> <ins> 2.5.5. </ins> The example belows shows how the client in trust domain A presents an authorization grant to the authorization server in trust domain B
2.3.2. <del> Either one of resource or audience is required to indicate for what authorization server the authorization grant should be audienced. The authorization server MUST deny the request if neither is set.  An authorization server SHOULD deny the request on an unknown resource/ audience.  In cases where federation to any authorization server is deliberate unknown resource or scope identifiers MAY be allowed. 2.3.3. </del> <ins> An authorization server SHOULD deny the request on an unknown resource or audience.  In cases where federation to any authorization server is deliberate unknown resource or audience identifiers MAY be allowed. </ins> The authorization server MAY deny the request due to policy.  For instance if federation to the requested domain/authorization
2.2. <del> The Identity Chaining flow outlined below describes how these specifications are used to address the use cases identified.  The appendix include two additional examples that describe how this flow is used when the resource server acts as the client an another that describes what happens when the authorization server acts as the client. </del> <ins> The Identity Chaining flow outlined below describes how a combination of OAuth 2.0 Token Exchange RFC8693 and Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants RFC7521 are used to address the use cases identified.  The appendix include two additional examples that describe how this flow is used.  In one example, the resource server acts as the client and in the other, the authorization server acts as the client. </ins> The flow illustrated in Figure 1 shows the steps the client in trust <del> domain A needs to perform to access a protected resource in trust </del> <ins> Domain A needs to perform to access a protected resource in trust </ins> domain B.  In this flow, the client has a way to discover the <del> authroization server in Domain B and a trust relationship exists between Domain A and Domain B (e.g. through federation).  It includes the following: </del> <ins> authorization server in Domain B and a trust relationship exists between Domain A and Domain B (e.g., through federation).  It includes the following: </ins> (A) The client of Domain A needs to discover the authorization server of Domain B.  See authorization-server-discovery. (B) The client exchanges its token at the authorization server of its own domain (Domain A) for an authorization grant that can be <del> used with the authorization server in Domain B.  See token- exchange. </del> <ins> used at the authorization server in Domain B.  See token-exchange. </ins> (C) The authorization server of Domain A processes the request and <del> returns an authorization grant that the client can use with Domain B.  This requires a trust relationship between Domain A and Domain B (e.g. through federation). </del> <ins> returns an authorization grant that the client can use with the authorization server of Domain B.  This requires a trust relationship between Domain A and Domain B (e.g., through federation). </ins> (D) The client presents the authorization grant to the <del> authorization server of Domain B.  See present-authorization- grant. </del> <ins> authorization server of Domain B.  See authorization-grant. </ins> (E) Authorization server of Domain B validates the authorization grant and returns an access token.