I've read all of the messages on here up until now, and so far (to summarize) there have been three main points which have been repeated quite a few times:
1) If you're going to specify a callback, you've got to sign it (otherwise the consumer can pre-specify it at the SP) 2) SP-generated nonces / callback nonces / callback tokens 3) One-time-only exchange requests (i.e. the request token is invalidated after the first attempt to exchange it for an access token) The first and last ones I get and I think we're all in agreement that they're a good way of plugging some of the holes in the spec; the second still seems a bit iffy, I don't quite get it as yet but from what I can tell it means the user has to go SP => consumer => SP => consumer, and it also seems relatively insecure. The whole vector of this attack is social engineering so, as I said previously, if the attacker can convince the user to authorize (her/him/it) then (she/he/ it) can probably also convince the user to enter a PIN. I've probably got it all wrong with the callback nonce, so could someone please explain how the flow of the callback nonce would work, and (if you're feeling really nice :-) how it significantly improves security? Just because I haven't seen a concise summary yet, and the ideas are littered all over the place. As for the other two, am I right in believing that a general consensus has been reached? Regards, Zack --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
