As far as 2,3, and 4, the window title approach is really irrelevant. Instead, the client will either directly handle callbacks through a custom scheme, or be able to recognize when a known callback URL has been loaded, and hence can extract the fragment from the URL directly.
I'm not sure it's cut-and-dry that the world will never need the copy-paste mechanism that Native Client flow supports, but from a usability perspective, we don't plan to deploy this and instead will be relying on callback techniques where ever possible. -cmort On 4/14/10 1:59 PM, "Marius Scurtescu" <mscurte...@google.com> wrote: On Wed, Apr 14, 2010 at 7:44 AM, Luke Shepard <lshep...@facebook.com> wrote: > Anyone have feedback on this? I can see several problems with using the User-Agent flow for native applications: 1. A verification code is much simpler to copy-and-paste (as opposed to access token + refresh token + lifetime). At the extreme, the verification code can be memorized and typed, this is impossible with the tokens. 2. Not in all cases a native application can intercept a token sent back to some callback URL. The native app could be a command line tool on a headless server, for example. Or, the user's default browser window does not show a custom title. 3. While it is feasible to extract a short verification code from a window title, that may not be possible with a long access token (it can end up truncated). Not to mention refresh token and lifetime. 4. Just redirecting to "about:blank#access_token=blahblahblah" is not reliable IMO. Try this in Firefox, nothing in the title. Same thing in Chrome will show the token in the title. I think the callback must render a proper HTML page with the proper <title> 5. Not clear that the User-Agent flow is safe enough to send back a refresh token. Was that decided? Marius The typical solution is for the native app to launch a browser and then watch that process and look for > > > > 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 > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
