!!! Overview
[{$pagename}]

Research such as the [ISO] [BASIN Document|https://www.cs.ox.ac.uk/people/cas.cremers/downloads/papers/BCM2012-iso9798.pdf|target='_blank'] points out that it is a [good practice|Best Practices] to explicitly state the intended interaction [endpoints] and the message position in the sequence in a tamper evident manner so that the intent of the initiator is unambiguous.  

!! [OAuth 2.0] [Endpoints]
The [endpoints] in [OAuth 2.0] that come into question are :
* [Protected Resources] [Endpoints]
* [Authorization Endpoint|authorization_endpoint] ("[authorization_endpoint]")
* [Redirection URI|authorization_endpoint] ("[redirect_uri]")
* [Token Endpoint|authorization_endpoint] ("[token_endpoint]")

Further, if dynamic [discovery|Discovery Mechanism] ([[OAuth 2.0 Authorization Server Metadata]]) is used, then the [metadata] related [endpoints] also come into question.

In [RFC 6749], while [Redirection URI|authorization_endpoint] is included, others are not included in the [Authorization Request].  As the result, the same applies to [Authorization Request] Object.

The lack of the link among those [endpoints] are sited as the cause of [Cross-Phase|Malicious Endpoint] [Attacks] introduced in [FETT].  An extension specification should be created as a measure to address the [risk].

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]