On Sat, Apr 25, 2009 at 1:19 PM, Josh Roesslein <[email protected]> wrote: > Yes we would need a way to still allow for manually providing these device > the callback token. > > The user can directly visit an authorization URL since their will be no > callback. > Example: http://service.example.com/authorize/testconsumer > > This URL can be provided by the consumer device. > > Once the user visits this URL they are prompted to log in to the provider > and approve access. > Next the provider gives the user the callback token which they then manually > enter into the device. > > Does that sound right?
Doesn't quite work because you need the callback token to be short enough to type. Short enough to type == short enough to brute force. In order to prevent that you need some kind of a longer secret (the request token secret) that is also required before the consumer gets an access token. If you include the request token secret and a callback token, you end up with https://oauth.pbwiki.com/Signed-Callback-URLs. (You can't use the consumer secret because in this scenario it's getting baked into installed applications and thus is not actually a secret.) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
