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
-~----------~----~----~----~------~----~------~--~---
