OAuth1.0, uses a single redirection-based flow to issue access token. OAuth2.0, overcomes these limitations, introducing several flow for different users and devices experience.
Using a unique shared secret to authenticate every Desktop client is a bad thing( you can also read section 4.6 in the OAuth specification(http://tools.ietf.org/html/rfc5849) which deals with client credentials that could be under the control of untrusted third parties). Regarding the callback problem, the desktop client could interact with the host web-browser, which in turn will open a specific URL on your server(request direct to the authorization endpoint). This page will then show a sort of PIN code(this is the oauth_verifier parameter introduced in the OAuth revision) that the user will enter inside a specific dialog box in the desktop client. After that, the desktop client, can continue in the OAuth process, requesting an access token. Cheers, Andrea. On Mar 3, 9:48 pm, Jeff <[email protected]> wrote: > I have a couple of questions. We are considering trying to write a > desktop client as a counterpart to our web-based OAuth system. The two > main issues are vetting of clients (so creating unique shared secrets > for each desktop client). is there a better way to do this? The next > issue has to do with clients that cannot get callbacks due to firewall > considerations. Is it possible to still have this be OAuth in this case? > Are there other practical workarounds people have used? > > Will OAuth 2 address either of these? We are committed to using OAuth > 1.0a for the near term, until there is a reference implementation for > OAuth 2. Any timeline on that? > > Thanks in Advance! > > Jeff -- 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.
