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.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. 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. 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 attributes leaking 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).