Failure does not exist in the protocol but in the implementation of many Oauth servers.
What happens is that the Oauth protocol redirects the user’s browser to the server authorization page, for example Facebook. Then a return URL is passed.
Facebook asks the user for permission so the application can access the Facebook API on behalf of the user. After the user authorizes, Facebook redirects to the return URL.
To prevent user abuse being redirected to an unauthorized website, Facebook checks whether the return URL is from the domain set up for that application.
However, there are abuse situations that indicate as return URL one of a page that redirects to another that is not the domain had authorized configured, thus managing to circumvent the verification.
Who has to fix the problem is mainly the Oauth server, for example Facebook, because in some modes of using the protocol already returns the direct authorization token to the return page without a proper verification.
However, if you have an application that uses Oauth to access the API of another site on behalf of its users, it may be that someone abuse your application to access user accounts on the Oauth server as if it were your application.
To avoid this problem, avoid having pages on your site redirect to arbitrary websites set as a parameter in the URL of the redirecting page.
The problem is more complicated, but this is the simplistic version that I believe can already understand what precautions should have.
I found this article, take a read: Serious security flaw in Oauth, Openid discovered
– Laerte
From what I understand, it is something that is part of Oauth, and it is up to the implementers to avoid the problem using a list of authorized domains (Whitelist). See http://it.slashdot.org/story/14/05/02/2015227/nasty-security-flaw-in-oauth-openid
– bfavaretto