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? On Sat, Apr 25, 2009 at 3: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). > > Signed callback URLs would let us keep request tokens and callback > tokens short enough to type or copy and paste. > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
