Can someone explain the "Covert Redirect" vulnerability in OAuth and OpenID?
This isn't a vulnerability of/in OAuth 2.0 at all. The issue has been wildly overblown and misstated by CNET and the original finder.
Here it is in a nutshell: If your web site (example.com) implements an open redirect endpoint - that is, implements a URL that will redirect the browser to any URL given in the URL parameters - AND your redirect copies URL parameters from the incoming URL to the outgoing redirect URL, then it is possible for third parties to exploit this artifact of your web site in a wide variety of nasty ways.
Worst case: evil.com is able to get the auth code originally intended for your web site (example.com) and may be able to use that auth code to extract user information from the auth provider (Google, Facebook, etc) or possibly even take control of the user's account on your web site.
Would evil.com be able to take control of the user's Google account using that access code? No, because the access code was minted for your site, example.com, and only works there.
Who's fault is it? Yours, for implementing an open redirect on your site. Don't blame Google or Facebook or others for your poor implementation.
There are a few legitimate use cases for having a redirect on your site. The biggest one is to redirect the browser after login to the web page (on your site) that the user originally requested. This only needs to redirect from your web site to pages in your web site, on your domain.
How to fix it? Have your redirect endpoint (example.com/redirect?&destination=ht.tp://foo.com...) validate the destination URL. Only allow redirects to pages on your site, in your domain.
More info on my blog: http://dannythorpe.com/2014/05/02/tech-analysis-of-serious-security-flaw-in-oauth-openid-discovered/
Update: There is an open redirect issue when using Facebook for OAuth user login. When you configure your app definition on Facebook, be sure to enter your domain-specific redirect URL in the redirect field provided. Facebook allows this field to be left blank. If left blank, Facebook itself acts as an open redirect while processing user logins for your web site.
Facebook should fix this by simply not allowing the redirect URL field to be left blank.
As others have stated, this is not a new idea. Eran Hammer (one of the creators of the Oauth 1.0 spec, who resigned from the Oauth 2.0 committe) wrote a good synopsis of the vulnerability, almost 3 years ago. His description didn't get a fancy logo or any sensational media coverage.
http://hueniverse.com/2011/06/21/oauth-2-0-redirection-uri-validation/
Here is a Youtube video the original finder put together leading you through the vulnerability: https://www.youtube.com/watch?v=HUE8VbbwUms.
OpenId and OAuth both provide a field that allows a third-party site to specify a redirect when authentication has completed and is successful. For instance, you go to Good Reads, they want you to login with your Facebook account. Good Reads will tell Facebook, "hey, when the user authenticates successfully, redirect them back to http://goodreads.com." The vulnerability is that some of these third-party sites allow redirects to be specified in their URLs (http://google.com/redirect?url=http://attacker.com) and may not validate them before they redirect the user. So, an attacker could create a "Login with Facebook" link for a valid site like Good Reads and could specify the redirect url to be something like http://goodreads.com/redirect?url=http://attacker.com (assuming Good Reads did this kind of redirect), your Facebook login popup would show that Good Reads (a perfectly normal site for you to be going to) wants to authenticate with Facebook, but when you authenticate and redirect back to Good Reads, if Good Reads doesn't validate the redirect URL, you'll be immediately redirected to http://attacker.com.
The fix would be for third-parties to validate redirects, but that may take a while to happen. The other thing is, CNet has reported that attackers might be able to steal information through this little interchange, but I'm not quite sure if that is possible. Someone else can comment on the matter. But, getting a user to a bad site is probably good enough for them.