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 specification.
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. ;-) Tom 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
