Well this callback is short lived since it is swapped by the consumer almost right away. So you don't have much time for a brute force attack to guess the callback URL. Plus we can require that you only get once try to swap the callback for an access token. After that it is invalidated and no longer useful.
On Sat, Apr 25, 2009 at 3:30 PM, Brian Eaton <[email protected]> wrote: > > On Sat, Apr 25, 2009 at 1:04 PM, Brian Eaton <[email protected]> wrote: > > On Sat, Apr 25, 2009 at 12:26 PM, Josh Roesslein <[email protected]> > wrote: > >> Thanks for posting that Brian. > >> > >> I'm leaning towards signed approval URLs. Seems the best way to go IMO. > >> Seems to solve the issues and also helps simplify the OAuth flow. > > > > The major pain point of signed approval URLs is that we would lose > > support for devices that either > > a) can't open a web browser (because the signed approval URL is really > long) > > or > > b) can't receive a callback URL (because the callback token is really > long). > > > > Err, I should have pointed out that the other objection I've heard to > signed approval URLs is that they are a major departure from the > current protocol, and thus will slow down deployment of fixes. I'm > not sure that's true, but it seems plausible. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
