On Wed, Apr 14, 2010 at 4:23 PM, Luke Shepard <[email protected]> wrote: > To get a verification code in the Native App scenario, the app either: > > 1/ Asks the user to copy/paste it. > 2/ Retrieves it programmatically. > > For 1/, I haven't seen a widely deployed desktop app use the copy/paste > scenario. For apps that do want the user to copy/paste a code, we have > designed the Device Flow just for that.
This forces the native app flow to rely on polling, and that makes it vulnerable to session fixation, just like OAuth 1.0, but much worse, because polling is a must in the flow. > For 2/, from my conversations with desktop developers, it is easier to grab > information from the URL than from the <title>. This is because you don't > have to parse and understand the content. It's also easier to poll for > changes in the URL (as results from a redirect) than to monitor the state of > the entire page. I can dig up some source examples if that's helpful. I agree that it is much nicer to parse a URL than messing with the title, but not sure how can this be done. Are you suggestion custom schemes? I don't think this is feasible in all cases. If you are suggesting a helper web app that receives the callback and provides the data to the client through some client/server call, then I think we are back to the device flow. > I'd like to ask the list again: has anyone deployed a desktop application, in > the wild, that uses a protocol close to the one that's proposed in the Native > Application flow? I've listed several apps below that use the flow I'm > proposing; I'd really like to highlight specific examples for the other side. I will check here at Google and get back to the list on that. Marius > > -----Original Message----- > From: Marius Scurtescu [mailto:[email protected]] > Sent: Wednesday, April 14, 2010 3:02 PM > To: Chuck Mortimore > Cc: Luke Shepard; OAuth WG > Subject: Re: [OAUTH-WG] Combining the Native application and User-agent flows > > 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
