On Tue, Apr 28, 2009 at 7:37 AM, Blaine Cook <rom...@gmail.com> wrote: > > On Tue, Apr 28, 2009 at 1:18 PM, Dossy Shiobara <do...@panoptic.com> wrote: >> >> If and only if the callback URL is protected from tampering. Since we >> cannot guarantee the consumer secret and request token secret to be ... >> well, secret ... there's no way to guarantee in ALL cases that the >> callback URL will be protected from tampering. > > If you can't guarantee the request token secret to be secret, then all > bets are off everywhere. OAuth has been designed such that the request > token secret *is* secret, and in the case of non-redistributed > consumers (e.g., web sites or open source software with a requirement > to obtain a new consumer key/secret), the consumer secret *is* also > secret.
That's exactly right: OAuth leverages the secrecy of the out-of-band agreement between consumer and SP. The request token is built upon that assumption, so it can safely be considered secret for the purposes of OAuth. > > For the callback URL signing case, it is absolutely possible to > guarantee that the request token secret remains private, and therefore > absolutely possible to ensure that the callback URL (and thus, the > verification token) is genuine. > While it is possible to tweak things to make sure the callback URL is genuine, that does not directly address the need to verify that the u...@consumer == u...@sp. Of course, it makes it highly probable and also makes an attack less likely (actually makes the attack in question impossible), but you are still relying on stateless HTTP transactions to establish "state" between SP & consumer & user. The only way I can see to accomplish that is to create out-of-band "state" on the user (e.g., a PIN or somesuch) that they carry from SP to consumer. --peter > My reading of Eran's proposal doesn't incorporate this level of > signing. That is, I *don't* see a proposal to actually include a > callback signature parameter in the callback URL, as in: > > http://example.com/callbackEndpoint?oauth_token=x&oauth_verifier=y&oauth_signature=HMAC-SHA1(oauth_token_secret, > Normalized("http://example.com/callbackEndpoint?oauth_token=x&oauth_verifier=y";)) > > It might be worthwhile, though, to do that? On the other hand, it > would significantly complicate things, and might not provide a > significant benefit, especially if both the callback URL and the > authorization endpoint were handled over SSL. > > b. > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
