Re: [OAUTH-WG] Combining the Native application and User-agent flows

[Evan Gilbert <[e-mail]>]

On Fri, Apr 16, 2010 at 8:09 PM, Eran Hammer-Lahav <[e-mail]>wrote:

>
>
>
> On 4/16/10 6:00 PM, "Evan Gilbert" <[e-mail]> wrote:
>
> > - Add text to the spec to give overview of options for native app
> developers
>
> I need a proposal.
>

Here's a proposal for text to cover the options for native applications

*3.8 Native Applications*
Applications running in an operating system that have the ability to launch
or embed a web browser can use any of the User Delegation flows or the End
User Credentials flow to get an access token for the user.

Some options for native applications:

   - Launch an external browser and have it redirect back to your app using
   a custom URI scheme. This works with the Web Server flow and User Agent
   flow.
   - Launch an external browser & poll for changes to the window title. This
   works with the Web Server flow with a custom redirect result page that puts
   the verification code in the title.
   - Use an embedded browser and read the redirect URL. This works with the
   Web Server flow and User Agent flow.
   - Use the Device profile with either an external or embedded browser. The
   application will open a browser and then poll the authorization server for
   results.
   - Use the Username and Password Flow and prompt the user for their
   credentials. This is generally discouraged as it hands the user's password
   directly to the 3rd party and may not work with more complex authentication
   schemes.

Factors in choosing between launching an external browser and an embedded
browser:

   - External browser may improve completion rate as the user may already be
   logged in and not have to re-enter username and password.
   - Embedded browser often has a better user flow, as you don't have to
   switch contexts and open a new window.
   - Embedded browser is less secure because users are entering their
   password in a screen within a target app.



>
> EHL
>
>