There is no signature url. In a way I guess the flow I am talking about is different than the signature auth flow.
1. User visits provider site: https://www.provider.com/oauth/authorize/testconsumer 2. User is presented with login page. 3. User grants access to the consumer. 4. Provider generates callback token that is easy for user to type into consumer device. 5. Consumer device swaps callback for access token like normal. On Sat, Apr 25, 2009 at 3:47 PM, Jonathan Sergent <[email protected]>wrote: > > You can't expect the user to type a URL with a signature in it, in the > case of a device that can't run a web browser. Sorry if I confused > the case we were talking about. > > On Sat, Apr 25, 2009 at 1:43 PM, Josh Roesslein <[email protected]> > wrote: > > How can the attacker use that flow? He can't set a callback in that URL > > since it can't be signed by him unless he has the consumer secrete. > > If there is no signiture, the provider ignores any parameters. It can > lookup > > to see if a default callback has been registered and use that. If there > is > > no default callback, the provider just displays the token for the user to > > manually enter. > > > > On Sat, Apr 25, 2009 at 3:39 PM, Jonathan Sergent <[email protected]> > > wrote: > >> > >> On Sat, Apr 25, 2009 at 1:38 PM, Josh Roesslein <[email protected]> > >> wrote: > >> > As for the timing to apply this change, I think it would be worth it > >> > taking > >> > the extra time to get it right. Most providers I think have already > >> > found > >> > quick fixes > >> > to block this session fixation attack. > >> > >> Really? The only "quick fix" I have seen is a scary warning message > >> on the approval page telling users not to use OAuth. > >> > >> > So I don't think we are in immediate > >> > danger, but I could be wrong. Just by adding callback URL signing and > >> > limiting request token swapping to one try should be enough to stop > the > >> > session fixation. > >> > > >> > On Sat, Apr 25, 2009 at 3:35 PM, Josh Roesslein <[email protected] > > > >> > wrote: > >> >> > >> >> 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 -~----------~----~----~----~------~----~------~--~---
