!!! Overview[1][2]
[{$pagename}] is a [Vulnerability] based on the premise that "The fragment is not passed to the server as part of the [URI] so the server could not include it in a [redirect|URL redirection]."


[{$pagename}] is part of a broader [Security Consideration] concerning [Unvalidated redirects and forwards]


However, some [browsers] ([User-agents]) have changed their behavior to preserve to append the [URI Fragment Identifiers] to the new [URI] from the Location [HTTP Header Field] of a [HTTP 302] redirect if it did not contain a [URI Fragment Identifiers].

!! [OAuth 2.0] and [OpenID Connect]
[{$pagename}] describes a process where a malicious [attacker] intercepts a request from an [OAuth Client] to an OAuth 2.0 [Authorization Server] and alters a [URI Query] parameter in the request called "[redirect_uri]" with the intention of causing the [Authorization Server] to direct the resulting OAuth Response to a malicious location rather than to the originally requesting [OAuth Client], thus exposing any returned secrets to the attacker. The [OAuth 2.0 Threat Model and Security Configurations] section-4.2.4 and [OAuth 2.0 Security-Closing Open Redirectors in OAuth] provides advice.

!! [Risk Assessment] [3]
1 If the [Identity Provider (IDP)] is [OpenID Connect] compliant, the risk should be negligible since [Relying Party] is expected to check that the full [redirect_uri] is not an [open redirect]. Even if it is an [open redirect], the [Relying Party] [MUST] check the [nonce] and [OAuth state parameter] as well, so unless another injection [vulnerability] exists in addition or the [Relying Party] is not [Validation] [nonce] and [OAuth state parameter] (means it is likely to be [XSRF] vulnerable), the [attacker] will not succeed.

2 If the server is OAuth 2.0 compliant, the risk should be low since [Relying Party] is expected to check that the [redirect_uri] does not become an [open redirect] depending on some [URI Query] component. Even if it is an [open redirect], the [Relying Party] is supposed to check the [OAuth state parameter] as well, so unless another injection vulnerability exists in addition or the RP is not checking state parameter (means it is [XSRF] vulnerable), the [attacker] will not succeed.

3 If the server is [OpenID Connect] compliant, and if the [OpenID Connect Provider] performs [Relying Party] discovery (and does exact match), the risk should be negligible since [Relying Party] is expected to check that the full [redirect_uri] is not an open redirector. 

4 If the server is [OpenID Connect] compliant but does not perform [Relying Party] discovery, and there is an [open redirect] in the [Relying Party], the risk comes from two aspects: user tracking and the [attribute leakage|Data Leakage]. Note: since there is no [access Token] equivalent in [OpenID Connect], the entire [OpenID Connect] operation is of lower risk than [OAuth] variants. 
* The risk posed by logging into a rogue web site by itself is not much higher than that of a [Tracking Cookie] or other AD Network unless the OP uses PPID. If the OP uses PPID, the risk gets lower and is more or less equivalent as a first party cookie, which is negligible.
* If the OP supports AX, then we would have to consider the risk of [Data Leakage] to the [attacker] and the risk depends on what attributes are going to be provided to the [attacker] while misleading the user to think that he is providing these attributes to the domain of the [redirect_uri].

5 If the server is [OpenID Connect] compliant and [Relying Party] lets its subpath to be controlled by a [Third-party], then the confusion [attack] is possible. However, this has been well known for many years as a downside of [OpenID Connect] in exchange to the feature that allows the sub-path to be treated as an independent [Relying Party]. This was an explicit feature and not a bug. In [OpenID Connect], the security domain is not the Authority section of the [URI] but the realm. Thus, the risk is evaluated to be less than in (4).


NOTE: The risk associated with a per site [Password-based] [authentication] is larger in this case because the [attacker] may obtain the [password] for the domain by confusing the user.


!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [OAuth 2 and Fragment encoding|http://www.thread-safe.com/2014/05/oauth-2-and-fragment-encoding.html|target='_blank'] - based on information obtained 2018-03-04
* [#2] - [OAuth Security Advisory: 2014.1 "Covert Redirect"|https://oauth.net/advisories/2014-1-covert-redirect/|target='_blank'] - based on information obtained 2018-03-04
* [#3] - [Covert Redirect is not new but|https://nat.sakimura.org/2014/05/08/covert-redirect-is-not-new/|target='_blank'] - based on information obtained 2018-03-21- 
* [#4] - [Insufficient Redirect URI Validation|https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.1|target='_blank'] - based on information obtained 2019-12-24