Tom,
   That was my first thought as well, but in that case, I would expect
the request failures to be randomly distributed and relatively
infrequent. In this case it fails every time (tested over a period of 6
hours yesterday). I've also not encountered this issue with any of the
other OAuth profiders we use: Google, Yahoo or LinkedIn. In the case of
Twitter, every request  using the standard user facing auth dance
succeeds as well. That said, I can certainly introduce an additional
factor to enhance the uniqueness of generated nonce values to test this
further.

With regard to Nonce uniqueness:
   "The nonce value MUST be unique across all requests with the same
   timestamp, client credentials, and token combinations."

Tom,
   Do you mean that Twitter is requiring global uniqueness within the
window of the previous 10 minutes, rather than uniqueness over the very
restricted subset of queries defined in the RFC? If that's the case,
then the issue I've encountered here will only become more pervasive as
more developers switch their implementations to OAuth over the next 13
days. This should be interesting...

Thanks,
Colin

On 8/17/10 10:19 AM, Tom van der Woerdt wrote:
> On 8/17/10 5:35 AM, Colin Hill wrote:
>> I ran into an issue when authenticating via OAuth, using the
>> token/secret pair offered for one of my apps, on the dev site (example)
>> http://dev.twitter.com/apps/12345/my_token
>>
>> we use the perl OAuth::Lite::Consumer module and have no difficulty
>> authenticating using the typical dance for our user facing web app, but
>> when migrating a cron job from basic to OAuth, using the generated token
>> pair as above, we now consistently get the following error:
>>
>> 401 Unauthorized
>> {"request":"/1/account/verify_credentials.json","error":"Invalid / used
>> nonce"}
>>
>> the passed OAuth Parameters are (consumer key redacted):
>>
>> $VAR1 = {
>>           'oauth_signature' => 'uHd1S9mCVG/dGNaHCFbl8vLHh2s=',
>>           'oauth_timestamp' => 1282000377,
>>           'oauth_consumer_key' => 'xxxxxxxxxxxxxxxxxxxxxxx',
>>           'oauth_nonce' => '95881ba3c50fa67a54fb',
>>           'oauth_version' => '1.0',
>>           'oauth_signature_method' => 'HMAC-SHA1'
>>         };
>>
>> I'm reasonably sure that this all worked when I wrote and tested it
>> three weeks back, but when I went to roll it into our cron job this
>> afternoon, authentication consistently fails. I wonder if anyone on the
>> list has seen a similar change in behavior, and/or could offer some
>> advice as to what might generate this error. Thanks.
>>
>>   -- Colin
> 
> Hi Colin,
> 
> Quoting RFC 5849 (OAuth 1.0) :
>    A nonce is a random string, uniquely generated by the client to allow
>    the server to verify that a request has never been made before and
>    helps prevent replay attacks when requests are made over a non-secure
>    channel.  The nonce value MUST be unique across all requests with the
>    same timestamp, client credentials, and token combinations.
> 
> In other words, it has to be unique.
> 
> I'm not entirely sure, but I *think* that Twitter's implementation of
> this says that it has to be unique, but you can re-use it after 10
> minutes. That might explain why it worked before.
> 
> Tom

Reply via email to