+1, at least for changing the wording of the current flows to deal with Native applications capable of various callback mechanisms.
That's the gist of this thread: http://www.ietf.org/mail-archive/web/oauth/current/msg01779.html -cmort On 4/14/10 7:44 AM, "Luke Shepard" <lshep...@facebook.com> wrote: Anyone have feedback on this? Sorry to push - we are in the midst of implementing this on a short timeline and it's important that we have clarity about the different flows. As it currently stands, I would not support the "Native Application Flow" and would instead tell desktop developers to use the "User-Agent Flow". But that is confusing and it would obviously be better if the flows were named correctly. Can someone persuade me otherwise? From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Luke Shepard Sent: Tuesday, April 13, 2010 1:36 PM To: OAuth WG Subject: [OAUTH-WG] Combining the Native application and User-agent flows In the latest draft of the OAuth 2.0 spec, there are four "User Delegation" flows: 3.4.1 Web Callback Flow 3.4.2 Native Application Flow 3.4.3 User-Agent Flow 3.4.4 Device Flow The Native Application and the User-Agent flows should be combined into one flow. The combined flow works for all client-side code. This is how it was in David's original draft; I'd love some help understanding why it was separated again. >From the draft: The native flow is intended for desktop applications where "the client is capable of interacting with the end user's user-agent but is incapable of receiving callback requests from the server (incapable of acting as an HTTP server) ... instead of using a callback to deliver the verification code to the client, the authorization server displays the verification code to the end user via its user-agent. If the client is able to interact with the user-agent, it retrieves the verification code automatically. Otherwise, the end user manually enters the verification code into a client dialog." So the flow is: 1/ User goes to oauth/authorize endpoint. 2/ Server displays a page that says something like "We are done here" and puts a code in the title. 3/ Desktop app makes a call to exchange the code for an access token, and closes the window. 4/ App uses access token. A simpler flow, which works for Desktop as well as Javascript apps, is: 1/ User goes to oauth/authorize endpoint. 2/ Server authorizes, then redirects to the callback url .. something like about:blank#access_token=blahblahblah 3/ App uses access token. At Facebook we have a lot of experience integrating with desktop apps. (i.e., Facebook for Adobe Air, Seesmic, Tweetdeck, iPhoto). In my experience, none of the desktop apps like to show a code that the user then enters into the app. Instead, apps typically receive the session (access token) directly in the response url. They can either use a URL on their domain, or a fake URL like about:blank, or an endpoint provided by Facebook (/connect/login_success.html). More info: http://wiki.developers.facebook.com/index.php/Authorization_and_Authentication_for_Desktop_Applications The access token never goes over the wire (it's in the fragment even if the url is legit) and the desktop app gets a more well-formatted response. I just don't get the point of the hacky code-in-html style. Can someone point me to a place where this is in widespread use today?
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
