rfc9700v4.txt		rfc9700.txt
	skipping to change at line 363 ¶		skipping to change at line 363 ¶
	token leakage vectors are mitigated.		token leakage vectors are mitigated.
	Clients SHOULD instead use the response type code (i.e.,		Clients SHOULD instead use the response type code (i.e.,
	authorization code grant type) as specified in Section 2.1.1 or any		authorization code grant type) as specified in Section 2.1.1 or any
	other response type that causes the authorization server to issue		other response type that causes the authorization server to issue
	access tokens in the token response, such as the code id_token		access tokens in the token response, such as the code id_token
	response type. This allows the authorization server to detect replay		response type. This allows the authorization server to detect replay
	attempts by attackers and generally reduces the attack surface since		attempts by attackers and generally reduces the attack surface since
	access tokens are not exposed in URLs. It also allows the		access tokens are not exposed in URLs. It also allows the
	authorization server to sender-constrain the issued tokens (see		authorization server to sender-constrain the issued tokens (see
	Section 2.2.		Section 2.2).
	2.2. Token Replay Prevention		2.2. Token Replay Prevention
	2.2.1. Access Tokens		2.2.1. Access Tokens
	A sender-constrained access token scopes the applicability of an		A sender-constrained access token scopes the applicability of an
	access token to a certain sender. This sender is obliged to		access token to a certain sender. This sender is obliged to
	demonstrate knowledge of a certain secret as a prerequisite for the		demonstrate knowledge of a certain secret as a prerequisite for the
	acceptance of that token at the recipient (e.g., a resource server).		acceptance of that token at the recipient (e.g., a resource server).
	skipping to change at line 985 ¶		skipping to change at line 985 ¶
	attack outlined below.		attack outlined below.
	Preconditions: For this variant of the attack to work, it is assumed		Preconditions: For this variant of the attack to work, it is assumed
	that		that
	* the implicit or authorization code grant is used with multiple		* the implicit or authorization code grant is used with multiple
	authorization servers of which one is considered "honest" (H-AS)		authorization servers of which one is considered "honest" (H-AS)
	and one is operated by the attacker (A-AS), and		and one is operated by the attacker (A-AS), and
	* the client stores the authorization server chosen by the user in a		* the client stores the authorization server chosen by the user in a
	session bound to the user's browser and uses the same redirection		session bound to the user's browser and uses the same redirection
	endpoint URI for each authorization server.		URI for each authorization server.
	In the following, it is further assumed that the client is registered		In the following, it is further assumed that the client is registered
	with H-AS (URI: https://honest.as.example, client ID: 7ZGZldHQ) and		with H-AS (URI: https://honest.as.example, client ID: 7ZGZldHQ) and
	with A-AS (URI: https://attacker.example, client ID: 666RVZJTA).		with A-AS (URI: https://attacker.example, client ID: 666RVZJTA).
	URLs shown in the following example are shortened for presentation to		URLs shown in the following example are shortened for presentation to
	include only parameters relevant to the attack.		include only parameters relevant to the attack.
	Attack on the authorization code grant:		Attack on the authorization code grant:
	1. The user selects to start the grant using A-AS (e.g., by clicking		1. The user selects to start the grant using A-AS (e.g., by clicking
	skipping to change at line 1042 ¶		skipping to change at line 1042 ¶
	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 an		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 (defined in
	to the attacker's resource server (since the client believes it		[OpenID.Core]) or a request to the attacker's resource server
	has completed the flow with A-AS).		(since the client believes it has completed the flow with A-AS).
	* Per-AS Redirect URIs: If clients use different redirection URIs		* Per-AS Redirect URIs: If clients use different redirection URIs
	for different authorization servers, clients do not store the		for different authorization servers, clients do not store the
	selected authorization server in the user's session, and		selected authorization server in the user's session, and
	authorization servers do not check the redirection URIs properly,		authorization servers do not check the redirection URIs properly,
	attackers can mount an attack called "Cross-Social Network Request		attackers can mount an attack called "Cross Social-Network Request
	Forgery". These attacks have been observed in practice. Refer to		Forgery". These attacks have been observed in practice. Refer to
	[research.jcs_14] for details.		[research.jcs_14] for details.
	* OpenID Connect: Some variants can be used to attack OpenID		* OpenID Connect: Some variants can be used to attack OpenID
	Connect. In these attacks, the attacker misuses features of the		Connect. In these attacks, the attacker misuses features of the
	OpenID Connect Discovery [OpenID.Discovery] mechanism or replays		OpenID Connect Discovery [OpenID.Discovery] mechanism or replays
	access tokens or ID Tokens to conduct a mix-up attack. The		access tokens or ID Tokens to conduct a mix-up attack. The
	attacks are described in detail in Appendix A of		attacks are described in detail in Appendix A of
	[arXiv.1704.08539] and Section 6 of [arXiv.1508.04324v2]		[arXiv.1704.08539] and Section 6 of [arXiv.1508.04324v2]
	("Malicious Endpoints Attacks").		("Malicious Endpoints Attacks").
End of changes. 4 change blocks.
	6 lines changed or deleted		6 lines changed or added
This html diff was produced by rfcdiff 1.48.