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 param with some argument like: http://provider.example.com/oauth/authorize?oauth_token=foobar123&oauth_callback=http%3A%2F%2Fconsumer.example.com%2Foauth%2Fcallback%2F%3Fnext%3Dhttp%253A%252F%252Fconsumer.example.com%252Fauth_finished%252F&oauth_signature=spamspamspamspam&oauth_signature_method=HMAC-SHA1 I don't know if you can read that with all the URL escapes, but basically the callback has been given a parameter called 'next' so that when my callback receives a request it will contain 'oauth_token' and 'next' as parameters. It can then redirect the user to an appropriate location. So if your website uses OAuth for log in (as some Twitter-centric web applications do, for example), it means you could log in from any page on the site and automatically end up at the same place you were before you started the log in process. Isn't that neat? I don't know if I've made myself very clear, but basically there are several uses of being able to change the callback URL, and if we can offer that flexibility with only the addition of a simple signature to the authorization URL, then there isn't a reason why we shouldn't do it. Regards, Zack On Apr 25, 7:08 am, Josh Roesslein <jroessl...@gmail.com> wrote: > I guess you could say the flow I proposed is a one token exchange. There is > only the access token that is returned back to the consumer > from the authorization callback. > > As for the whole callback parameter, I don't like it at all. I see it as bad > practice of dynamically setting this URL. > It should be possible to just use a single URL that you register with the > provider. I just can't think of an use case that would require a dynamic > callback. > > > > On Sat, Apr 25, 2009 at 12:00 AM, Dossy Shiobara <do...@panoptic.com> wrote: > > > On 4/25/09 12:31 AM, pkeane wrote: > > > If I am following correctly, this should work. But there are a few > > > drawbacks I see. It is fairly dramatically different from the way > > > OAuth works now for all parties: user, consumer, provider. > > > Right. OAuth, as it is specified in 1.0, has flaws that will require > > changes that affect all parties. > > > > It also seems quite complex (maybe I am being dense :) to me, a > > > hallmark of a good security scheme is simplicity and clarity to the > > > extent possible. > > > I dunno, it seems remarkably simple to me. Matter of fact, I don't see > > any ways to make it any simpler without losing important security. > > > -- > > 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 -~----------~----~----~----~------~----~------~--~---
