w/r/t attempt-limiting, You can limit the attempts based on the token that the consumer is attempting to exchange.
Also, I've noticed that there isn't much difference between the two methods. A request token is essentially an alias, known to both the consumer and service provider, for the following parameters: oauth_consumer_key oauth_signature oauth_signature_method oauth_timestamp oauth_nonce oauth_version So request tokens hide all (or most) of these parameters behind a simple string alias, giving the user a more simple URL (maybe with the additional oauth_callback, oauth_signature and oauth_signature_method parameters). But to be honest, my major gripe with the Signed Approval URL system is that it leaves it up to the client to do what would be usually done by the consumer. So what happens if this request fails? If the consumer were using request tokens, then it would know that it couldn't get a request token and might be able to display a customized error message to the user (something like 'We seem to be having issues.'). However, allowing the user to get the 401 Unauthorized error from the Service Provider might seem a little odd for the user; what's worse, the consumer wouldn't have a clue anything was wrong until an irate user sent them an e-mail complaining (whereas, if getting the request token failed, the system administrators might get an e-mail from their application). My interest in this mostly centers around the fact that I'm currently implementing an OAuth consumer, and I'm also the maintainer of an unpopular OAuth client library for Python. But I thought it a good idea to throw this into the conversation. Regards, Zack On Apr 25, 11:10 pm, Brian Eaton <bea...@google.com> wrote: > On Sat, Apr 25, 2009 at 1:35 PM, Josh Roesslein <jroessl...@gmail.com> wrote: > > Plus we can require that you only get once try to swap the callback for an > > access token. After that it is invalidated and no longer useful. > > You can't actually do that in the flow you proposed. In order to > limit the number of attempts you need some way to identify the client > making the request, and your flow doesn't provide any way to do that > reliably. (IP address is not sufficient, and not viable at all at > scale.) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---