OAuth 2.0 Security Best Current Practice - IETF

Examples for such attacks include open redirector attacks, insufficient checking of redirect URIs (see Section 4.1), problems existing on mobile operating systems (where different apps can register themselves on the same URI), mix-up attacks (see Section 4.4), where the client is tricked into sending credentials to an attacker-controlled authorization server, and the fact that URLs are often stored/logged by browsers (history), proxy servers, and operating systems.¶ … This approach turned out to be more complex to implement and more error prone to manage than exact redirect URI matching. Several successful attacks exploiting flaws in the pattern matching implementation or concrete configurations have been observed in the wild (see, e.g., [research.rub2]). Insufficient validation of the redirect URI effectively breaks client identification or authentication (depending on grant and client type) and allows the attacker to obtain an authorization code or access token, either¶ - by directly sending the user agent to a URI under the attackers control, or¶ - by exposing the OAuth credentials to an attacker by utilizing an open redirector at the client in conjunction with the way user agents handle URL fragments.¶ These attacks are shown in detail in the following subsections.¶