On Wed, Apr 14, 2010 at 2:19 PM, Chuck Mortimore <[email protected]> wrote: > 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.
This is a very strong limitation, only native apps that can register and handle a custom scheme will work. What do we get in return, just a slight simplification in the spec? Assuming simplification is the main driver, I think it is feasible to combine Web Callback and Native Application, with no penalty. Marius > > 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" <[email protected]> wrote: > > On Wed, Apr 14, 2010 at 7:44 AM, Luke Shepard <[email protected]> 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: [email protected] [mailto:[email protected]] 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
