On 4/23/09 9:00 PM, pkeane wrote: > actually, I would say you need to make sure the person initiating the > request is the same person initiating the authorization. It needn't > be tied into actual user accounts. As far as I understand, consumers > might not even have a notion of "user" beyond session state. That's > why I had suggested PIN, but....
Right. The obvious solution is to require the user to _authenticate_ with Provider in ORDER to first get a request token, which can then be _authorized_. This way, an attacker can't generate a request token for a user they can't first authenticate as, so that there's no request token to pawn off on a hapless victim to authorize. Somewhere, fairly loudly, I'm sure the AOL Screen Name Service people and MSN Passport folks are laughing at all of us. And, rightfully so. -- Dossy Shiobara | [email protected] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
