On 4/17/09 7:00 PM, John Kristian wrote: > OAuth concentrates on securing communication between the consumer and > service provider. The callback is just a timing signal, telling the > consumer it can continue its interaction with the service provider. > Nothing sensitive is transmitted via the callback. > > In other words, attempting to transmit something sensitive via an > OAuth callback is a mistake. OAuth wasn't designed for this.
Oh, I don't care about transmitting sensitive data via the OAuth callback. I just want to eliminate replay attacks - you're absolutely right, the callback is a form of IPC to the consumer ... which presumably will go on to perform other tasks once it receives the signal. Depending on what those tasks are, it's very desirable to be able to tell if the callback was legitimate or either a replay attack or a brute-force token shooting attack. Even client-side browser cookies may not win here if a simple session fixation attack is coupled with the token shooting attack. Exactly what's the harm in signing the callback URL? -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
