Hi David,
I found this to be an issue actually; in a shameless plug of my own
OAuth client library for Python, ZOAuth [1], I found that functions
like urllib.urlencode() were turning out URLs with '+' instead of the
(expected) '%20'. This is due to the presence of two functions:
urllib.quote()
I agree with Josh on most points:
* I have no alternative suggestions, and I am for the Signed Callback
URL solution.
* I think the parameter returned in 6.2.3 should be separate from the
request token in 6.3.1 for security reasons (brute forcing), and also
because the request token's secret is
The dynamic callbacks are not so much for changing the domain or path
but for adding extra parameters. OAuth Core 1.0 specifies that any
parameters specified on the callback URL must remain there and be
passed back unmodified to the callback. For example:
I pass the user auth URL a callback
I completely agree. The whole point of this thread (I thought) was to
develop a solution to a very specific security hole; this has already
been done with three things: once-only exchanging, signed/pre-
specified callbacks, and the concept of a callback nonce (a.k.a.
authorization token, and a
and don't really affect the current
oauth flow.
On Sat, Apr 25, 2009 at 4:31 PM, Zachary Voase
disturb...@googlemail.comwrote:
I completely agree. The whole point of this thread (I thought) was to
develop a solution to a very specific security hole; this has already
been done with three
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
OK, I definitely see what you mean with the callback nonce now and I
completely agree that it plugs that last hole (where the attacker
beats the user to the callback URL). Most of the messages preceding
this one talked about callback nonces as these things that get
generated with the request
I've since had the whole concept of callback nonces explained to me by
Mike Malone in an earlier post here and so I retract what I said
before about callback nonces (I had a different idea of what they
were).
On Apr 24, 8:24 pm, pkeane pjke...@gmail.com wrote:
On Apr 24, 11:37 am, Zachary Voase
I'd like to propose the following flow (which is basically an
amalgamation of a few ideas throughout this thread):
1) User visits Consumer's website, Consumer gets request token
from Service Provider.
2) Consumer sends user to the Service Provider's user auth URL,
with 'oauth_token' and
It's not that the malicious software is scanning for access tokens,
but that the attacker gets the consumer secret for the desktop
application; this would allow the attacker to exchange request tokens
for access tokens, etc. (as the attacker has essentially compromised
the consumer, not the
10 matches
Mail list logo
