Notice how above I first blamed the browsers for not solving the problem, but then ended up sharing the blame with OAuth. That's because a) the UI redressing problem is not specific to OAuth and b) UI redressing is a super-tricky problem to solve. Simply displaying the URL of an iframe (even if browser assisted) is not nearly enough because that too can be easily redressed (see more at http://www.webmonkey.com/2008/10/a_look_at_the__clickjacking__web_attack_and_why_you_should_worry/). Browser developers do are trying to do something about the problem but they just don't agree on exactly what is the right measure (see e.g http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016286.html).
To improve usability without asking for user's credentials in the same Oauth authorization dialog, Facebook could potentially allow passing a one-time valid user authentication token with the Oauth request, but in some ways that would only shift the responsibility somewhere else. There's an open standard for that as well, called OpenID, and you can by all means use OpenID together with OAuth as demonstrated by Google . Unfortunately though, the window redressing attack is just as big of a problem for OpenID as it is for OAuth. Since OpenID was originally meant for authentication only (though the attribute extensions make it partly an authorization technique) you cannot shift the responsibility any further. I'm not advocating the use of hybrid OpenID+Oauth model either - it may just increase complexity without improving user experience. However, we may be throwing the baby out with the bath water by never allowing Oauth dialogs to be shown in iframes. Certainly the authorization server has to be able to authenticate the end user one way or another, but handling an Oauth callback in an iframe is perfectly secure if you never ask the user's password in the same dialog. Anyhow, with the current standards there's no way out without major security implications, so browsers and ultimately, newer standards need to provide a better, more secure solution.
With 600 million users and counting, it's the new Internet. Yes, I'm talking about Facebook. Whether you love it or hate it, these days you have to have a Facebook strategy. Every other site is doing Facebook, Twitter and Google integrations and why not, your fledgling little website wouldn't need more than 1/1000th of their users to make it a success. So why is that everybody needs to suffer on their own through implementing various versions of Oauth & other open authorization standards? With that suffering in mind, tynamo-federatedaccounts, a module for supporting remote authentication and merged (federated) authorization, was born.
I've been using various versions of more specialized implementations of the same concept before, but tynamo-federatedaccounts is the first attempt at generalizing Oauth & similar work flows to an easy-to-use package. The module is based on Tynamo's tapestry-security, a stable and well-maintained security package based on Apache Shiro for Tapestry5 applications. At this point, I'm looking for early user feedback for the current implementation and APIs. I've put together a simple, live demonstration to showcase it. Also check out the documentation for tynamo-federatedaccounts.