rfc9700v2.txt		rfc9700.txt
	skipping to change at line 314 ¶		skipping to change at line 314 ¶
	preventing the use of constant values for the PKCE challenge or		preventing the use of constant values for the PKCE challenge or
	OpenID Connect nonce.		OpenID Connect nonce.
	Note: Although PKCE was designed as a mechanism to protect native		Note: Although PKCE was designed as a mechanism to protect native
	apps, this advice applies to all kinds of OAuth clients, including		apps, this advice applies to all kinds of OAuth clients, including
	web applications.		web applications.
	When using PKCE, clients SHOULD use PKCE code challenge methods that		When using PKCE, clients SHOULD use PKCE code challenge methods that
	do not expose the PKCE verifier in the authorization request.		do not expose the PKCE verifier in the authorization request.
	Otherwise, attackers that can read the authorization request (cf.		Otherwise, attackers that can read the authorization request (cf.
	attacker (A4) in Section 3) can break the security provided by PKCE.		Attacker (A4) in Section 3) can break the security provided by PKCE.
	Currently, S256 is the only such method.		Currently, S256 is the only such method.
	Authorization servers MUST support PKCE [RFC7636].		Authorization servers MUST support PKCE [RFC7636].
	If a client sends a valid PKCE code_challenge parameter in the		If a client sends a valid PKCE code_challenge parameter in the
	authorization request, the authorization server MUST enforce the		authorization request, the authorization server MUST enforce the
	correct usage of code_verifier at the token endpoint.		correct usage of code_verifier at the token endpoint.
	Authorization servers MUST mitigate PKCE downgrade attacks by		Authorization servers MUST mitigate PKCE downgrade attacks by
	ensuring that a token request containing a code_verifier parameter is		ensuring that a token request containing a code_verifier parameter is
	skipping to change at line 447 ¶		skipping to change at line 447 ¶
	web origin.		web origin.
	2.5. Client Authentication		2.5. Client Authentication
	Authorization servers SHOULD enforce client authentication if it is		Authorization servers SHOULD enforce client authentication if it is
	feasible, in the particular deployment, to establish a process for		feasible, in the particular deployment, to establish a process for
	issuance/registration of credentials for clients and ensuring the		issuance/registration of credentials for clients and ensuring the
	confidentiality of those credentials.		confidentiality of those credentials.
	It is RECOMMENDED to use asymmetric cryptography for client		It is RECOMMENDED to use asymmetric cryptography for client
	authentication, such as mTLS [RFC8705] or signed JWTs ("Private Key		authentication, such as mutual TLS for OAuth 2.0 [RFC8705] or signed
	JWT") in accordance with [RFC7521] and [RFC7523]. The latter is		JWTs ("Private Key JWT") in accordance with [RFC7521] and [RFC7523].
	defined in [OpenID.Core] as the client authentication method		The latter is defined in [OpenID.Core] as the client authentication
	private_key_jwt). When asymmetric cryptography for client		method private_key_jwt). When asymmetric cryptography for client
	authentication is used, authorization servers do not need to store		authentication is used, authorization servers do not need to store
	sensitive symmetric keys, making these methods more robust against		sensitive symmetric keys, making these methods more robust against
	leakage of keys.		leakage of keys.
	2.6. Other Recommendations		2.6. Other Recommendations
	The use of OAuth Authorization Server Metadata [RFC8414] can help to		The use of OAuth Authorization Server Metadata [RFC8414] can help to
	improve the security of OAuth deployments:		improve the security of OAuth deployments:
	* It ensures that security features and other new OAuth features can		* It ensures that security features and other new OAuth features can
	skipping to change at line 606 ¶		skipping to change at line 606 ¶
	authorization server. For example, a resource server may be		authorization server. For example, a resource server may be
	compromised by an attacker, an access token may be sent to an		compromised by an attacker, an access token may be sent to an
	attacker-controlled resource server due to a misconfiguration,		attacker-controlled resource server due to a misconfiguration,
	or social engineering may be used to get a resource owner to		or social engineering may be used to get a resource owner to
	use an attacker-controlled resource server. Also see		use an attacker-controlled resource server. Also see
	Section 4.9.2.		Section 4.9.2.
	(A3), (A4), and (A5) typically occur together with either (A1) or		(A3), (A4), and (A5) typically occur together with either (A1) or
	(A2). Attackers can collaborate to reach a common goal.		(A2). Attackers can collaborate to reach a common goal.
	Note that an attacker (A1) or (A2) can be a resource owner or act as		Note that an Attacker (A1) or (A2) can be a resource owner or act as
	one. For example, such an attacker can use their own browser to		one. For example, such an attacker can use their own browser to
	replay tokens or authorization codes obtained by any of the attacks		replay tokens or authorization codes obtained by any of the attacks
	described above at the client or resource server.		described above at the client or resource server.
	This document focuses on threats resulting from attackers (A1) to		This document focuses on threats resulting from Attackers (A1) to
	(A5).		(A5).
	4. Attacks and Mitigations		4. Attacks and Mitigations
	This section gives a detailed description of attacks on OAuth		This section gives a detailed description of attacks on OAuth
	implementations, along with potential countermeasures. Attacks and		implementations, along with potential countermeasures. Attacks and
	mitigations already covered in [RFC6819] are not listed here, except		mitigations already covered in [RFC6819] are not listed here, except
	where new recommendations are made.		where new recommendations are made.
	This section further defines additional requirements (beyond those		This section further defines additional requirements (beyond those
	skipping to change at line 958 ¶		skipping to change at line 958 ¶
	Countermeasures:		Countermeasures:
	* Clients MUST NOT pass access tokens in a URI query parameter in		* Clients MUST NOT pass access tokens in a URI query parameter in
	the way described in Section 2.3 of [RFC6750]. The authorization		the way described in Section 2.3 of [RFC6750]. The authorization
	code grant or alternative OAuth response modes like the form post		code grant or alternative OAuth response modes like the form post
	response mode [OAuth.Post] can be used to this end.		response mode [OAuth.Post] can be used to this end.
	4.4. Mix-Up Attacks		4.4. Mix-Up Attacks
	Mix-up attacks are in scenarios where an OAuth client interacts with		Mix-up attacks can occur in scenarios where an OAuth client interacts
	two or more authorization servers and at least one authorization		with two or more authorization servers and at least one authorization
	server is under the control of the attacker. This can be the case,		server is under the control of the attacker. This can be the case,
	for example, if the attacker uses dynamic registration to register		for example, if the attacker uses dynamic registration to register
	the client at their own authorization server or if an authorization		the client at their own authorization server or if an authorization
	server becomes compromised.		server becomes compromised.
	The goal of the attack is to obtain an authorization code or an		The goal of the attack is to obtain an authorization code or an
	access token for an uncompromised authorization server. This is		access token for an uncompromised authorization server. This is
	achieved by tricking the client into sending those credentials to the		achieved by tricking the client into sending those credentials to the
	compromised authorization server (the attacker) instead of using them		compromised authorization server (the attacker) instead of using them
	at the respective endpoint of the uncompromised authorization/		at the respective endpoint of the uncompromised authorization/
	skipping to change at line 1033 ¶		skipping to change at line 1033 ¶
	code for an access token (for public clients) or perform an		code for an access token (for public clients) or perform an
	authorization code injection attack as described in Section 4.5.		authorization code injection attack as described in Section 4.5.
	Variants:		Variants:
	* Mix-Up with Interception: This variant works only if the attacker		* Mix-Up with Interception: This variant works only if the attacker
	can intercept and manipulate the first request/response pair from		can intercept and manipulate the first request/response pair from
	a user's browser to the client (in which the user selects a		a user's browser to the client (in which the user selects a
	certain authorization server and is then redirected by the client		certain authorization server and is then redirected by the client
	to that authorization server), as in Attacker (A2) (see		to that authorization server), as in Attacker (A2) (see
	Section 3). This capability can, for example, be the result of a		Section 3). This capability can, for example, be the result of an
	attacker-in-the-middle attack on the user's connection to the		attacker-in-the-middle attack on the user's connection to the
	client. In the attack, the user starts the flow with H-AS. The		client. In the attack, the user starts the flow with H-AS. The
	attacker intercepts this request and changes the user's selection		attacker intercepts this request and changes the user's selection
	to A-AS. The rest of the attack proceeds as in Step 2 and		to A-AS. The rest of the attack proceeds as in Step 2 and
	following above.		following above.
	* Implicit Grant: In the implicit grant, the attacker receives an		* Implicit Grant: In the implicit grant, the attacker receives an
	access token instead of the code in Step 4. The attacker's		access token instead of the code in Step 4. The attacker's
	authorization server receives the access token when the client		authorization server receives the access token when the client
	makes either a request to the A-AS userinfo endpoint or a request		makes either a request to the A-AS userinfo endpoint or a request
	to the attacker's resource server (since the client believes it		to the attacker's resource server (since the client believes it
	skipping to change at line 1147 ¶		skipping to change at line 1147 ¶
	4.5. Authorization Code Injection		4.5. Authorization Code Injection
	An attacker who has gained access to an authorization code contained		An attacker who has gained access to an authorization code contained
	in an authorization response (see Attacker (A3) in Section 3) can try		in an authorization response (see Attacker (A3) in Section 3) can try
	to redeem the authorization code for an access token or otherwise		to redeem the authorization code for an access token or otherwise
	make use of the authorization code.		make use of the authorization code.
	In the case that the authorization code was created for a public		In the case that the authorization code was created for a public
	client, the attacker can send the authorization code to the token		client, the attacker can send the authorization code to the token
	endpoint of the authorization server and thereby get an access token.		endpoint of the authorization server and thereby get an access token.
	This attack was described in Section 4.4.1.1. of [RFC6819].		This attack was described in Section 4.4.1.1 of [RFC6819].
	For confidential clients, or in some special situations, the attacker		For confidential clients, or in some special situations, the attacker
	can execute an authorization code injection attack, as described in		can execute an authorization code injection attack, as described in
	the following.		the following.
	In an authorization code injection attack, the attacker attempts to		In an authorization code injection attack, the attacker attempts to
	inject a stolen authorization code into the attacker's own session		inject a stolen authorization code into the attacker's own session
	with the client. The aim is to associate the attacker's session at		with the client. The aim is to associate the attacker's session at
	the client with the victim's resources or identity, thereby giving		the client with the victim's resources or identity, thereby giving
	the attacker at least limited access to the victim's resources.		the attacker at least limited access to the victim's resources.
	skipping to change at line 1542 ¶		skipping to change at line 1542 ¶
	servers (see Attackers (A1) and (A5) in Section 3). If the client		servers (see Attackers (A1) and (A5) in Section 3). If the client
	sends a valid access token to this counterfeit resource server, the		sends a valid access token to this counterfeit resource server, the
	attacker in turn may use that token to access other services on		attacker in turn may use that token to access other services on
	behalf of the resource owner.		behalf of the resource owner.
	This attack assumes the client is not bound to one specific resource		This attack assumes the client is not bound to one specific resource
	server (and its URL) at development time, but client instances are		server (and its URL) at development time, but client instances are
	provided with the resource server URL at runtime. This kind of late		provided with the resource server URL at runtime. This kind of late
	binding is typical in situations where the client uses a service		binding is typical in situations where the client uses a service
	implementing a standardized API (e.g., for email, calendaring,		implementing a standardized API (e.g., for email, calendaring,
	healthcare, or banking) and where the client is configured by a user		eHealth, or open banking) and where the client is configured by a
	or administrator.		user or administrator.
	4.9.2. Compromised Resource Server		4.9.2. Compromised Resource Server
	An attacker may compromise a resource server to gain access to the		An attacker may compromise a resource server to gain access to the
	resources of the respective deployment. Such a compromise may range		resources of the respective deployment. Such a compromise may range
	from partial access to the system, e.g., its log files, to full		from partial access to the system, e.g., its log files, to full
	control over the respective server, in which case all controls can be		control over the respective server, in which case all controls can be
	circumvented and all resources can be accessed. The attacker would		circumvented and all resources can be accessed. The attacker would
	also be able to obtain other access tokens held on the compromised		also be able to obtain other access tokens held on the compromised
	system that would potentially be valid to access other resource		system that would potentially be valid to access other resource
	skipping to change at line 1628 ¶		skipping to change at line 1628 ¶
	tied to specific material provided by the transport layer (e.g.,		tied to specific material provided by the transport layer (e.g.,
	TLS). The resource server must also ensure that a replay of the		TLS). The resource server must also ensure that a replay of the
	proof of possession is not possible.		proof of possession is not possible.
	Two methods for sender-constrained access tokens using proof of		Two methods for sender-constrained access tokens using proof of
	possession have been defined by the OAuth working group and are in		possession have been defined by the OAuth working group and are in
	use in practice:		use in practice:
	* "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound		* "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound
	Access Tokens" [RFC8705]: The approach specified in this) document		Access Tokens" [RFC8705]: The approach specified in this) document
	allows the use of mutual TLS (mTLS) for both client authentication		allows the use of mutual TLS for both client authentication and
	and sender-constrained access tokens. For the purpose of sender-		sender-constrained access tokens. For the purpose of sender-
	constrained access tokens, the client is identified towards the		constrained access tokens, the client is identified towards the
	resource server by the fingerprint of its public key. During the		resource server by the fingerprint of its public key. During the
	processing of an access token request, the authorization server		processing of an access token request, the authorization server
	obtains the client's public key from the TLS stack and associates		obtains the client's public key from the TLS stack and associates
	its fingerprint with the respective access tokens. The resource		its fingerprint with the respective access tokens. The resource
	server in the same way obtains the public key from the TLS stack		server in the same way obtains the public key from the TLS stack
	and compares its fingerprint with the fingerprint associated with		and compares its fingerprint with the fingerprint associated with
	the access token.		the access token.
	* "OAuth 2.0 Demonstrating Proof of Possession (DPoP)" [RFC9449]:		* "OAuth 2.0 Demonstrating Proof of Possession (DPoP)" [RFC9449]:
	DPoP outlines an application-level mechanism for sender-		DPoP outlines an application-level mechanism for sender-
	skipping to change at line 1703 ¶		skipping to change at line 1703 ¶
	benefit to hide the resource server URL from the authorization		benefit to hide the resource server URL from the authorization
	server.		server.
	Audience restriction may seem easier to use since it does not require		Audience restriction may seem easier to use since it does not require
	any cryptography on the client side. Still, since every access token		any cryptography on the client side. Still, since every access token
	is bound to a specific resource server, the client also needs to		is bound to a specific resource server, the client also needs to
	obtain a single resource server-specific access token when accessing		obtain a single resource server-specific access token when accessing
	several resource servers. (Resource indicators, as specified in		several resource servers. (Resource indicators, as specified in
	[RFC8707], can help to achieve this.) [TOKEN-BINDING] had the same		[RFC8707], can help to achieve this.) [TOKEN-BINDING] had the same
	property since different token-binding IDs must be associated with		property since different token-binding IDs must be associated with
	the access token. Using Mutual TLS for OAuth 2.0 [RFC8705], on the		the access token. Using mutual TLS for OAuth 2.0 [RFC8705], on the
	other hand, allows a client to use the access token at multiple		other hand, allows a client to use the access token at multiple
	resource servers.		resource servers.
	It should be noted that audience restrictions -- or, generally		It should be noted that audience restrictions -- or, generally
	speaking, an indication by the client to the authorization server		speaking, an indication by the client to the authorization server
	where it wants to use the access token -- have additional benefits		where it wants to use the access token -- have additional benefits
	beyond the scope of token leakage prevention. They allow the		beyond the scope of token leakage prevention. They allow the
	authorization server to create a different access token whose format		authorization server to create a different access token whose format
	and content are specifically minted for the respective server. This		and content are specifically minted for the respective server. This
	has huge functional and privacy advantages in deployments using		has huge functional and privacy advantages in deployments using
End of changes. 10 change blocks.
	16 lines changed or deleted		16 lines changed or added
This html diff was produced by rfcdiff 1.48.