This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Explicit Endpoint
Explicit Endpoint

Version management

Difference between version and

At line 1 added 21 lines
!!! 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' }]
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop