Brian Eaton wrote: > There are a few options. > > 1) Keep using OAuth 1.0. > SPs can tell users that they are authorizing an application on > their desktop. There is some risk of social engineering as you > describe, but hopefully the language on service provider pages > mentioning desktop applications will help. > > 2) Callback token displayed on page. > SPs can display a callback token, which the user will manually > enter into their desktop application. This is not a good user > experience, but provides better security than option 1. > > 3) Callback token sent to desktop app. > There are a bunch of ways to get a callback token to a desktop app > automatically, most of them mentioned earlier in this thread. > 4) The Callback URL is registered with the Provider at the time that the Consumer Key and Secret are issued.
This is pretty much what Facebook does and removes the idea of having the callback appearing anywhere in the handshake. Yes, it means that you can't have pure, dynamically generated URLs. Yes, it means extra work and storage for service providers. It also means that the end user doesn't have to do anything extra in order to continue using OAuth, which should be one of the bigger goals. I'm pretty sure I'm missing something here, so feel free to chime in why this is dumb. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
