A (temporary) fix might be for Service Providers to check the HTTP Referer request header when Users arrives at the authorization URI.
If the Referer “matches” the application associated with the request token then the User has not come from an Attacker’s link. A Referer check at the SP requires no change to consumer applications. For desktop applications, the SP could check that the Referer field is absent (though I believe this can be readily spoofed, eg redirect the user through a FTP URI). P.S. I don’t think an open redirector at the application’s web site defeats the Referer check as the Referer field still lists the original URI, not the URI that issued the redirect (at least in my quick test with Firefox 3). James Manger james.h.man...@team.telstra.com<mailto:james.h.man...@team.telstra.com> Identity and security team — Chief Technology Office — Telstra --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
