On Fri, Apr 16, 2010 at 8:09 PM, Eran Hammer-Lahav <e...@hueniverse.com>wrote:
> > > > On 4/16/10 6:00 PM, "Evan Gilbert" <uid...@google.com> 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 > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
