I'll quote some more :
   To avoid the need to retain an infinite number of nonce values for
   future checks, servers MAY choose to restrict the time period after
   which a request with an old timestamp is rejected.  Note that this
   restriction implies a level of synchronization between the client's
   and server's clocks.  Servers applying such a restriction MAY provide
   a way for the client to sync with the server's clock; alternatively,
   both systems could synchronize with a trusted time service.  Details
   of clock synchronization strategies are beyond the scope of this

That's what I meant ;-)

And no, the nonce values are per app per user, like the specification
says :-) I personally prefer PHP's uniqid() to generate nonces.

Also, like Taylor said, check your timestamp etc. ;-)


On 8/17/10 4:59 PM, Colin Hill wrote:
> 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