Re: [OAUTH-WG] Updated text for Native Apps

[Anthony Nadalin <[e-mail]>]

Not seeing what you write about below, I think that the basic text that was discussed at the F2F has consensus around the guidance (with some changes that were discussed and Chuck provided), I think that some of the other thoughts people have thrown out don't. I disagree with dropping the text as there is not consensus to do that, since there was an action item to put text back in.

From: Eran Hammer-Lahav [mailto:[e-mail]]
Sent: Wednesday, June 15, 2011 10:19 AM
To: Anthony Nadalin; Chuck Mortimore; [e-mail]
Subject: RE: Updated text for Native Apps

This working group has failed, for well over a year, to reach any sort of consensus regarding which grant types are suitable for a given client type. There was no draft between 00 and 16 in which we had agreement on the definition of client types, or the exclusivity of any flow to any given type. Trying to reach such a conclusion is a waste of time.

The main reason for this is lack of deployment experience. We have pretty good experience with some cases like a server-based client capable of keeping secrets, and browser-based clients executing fully visible source code. We clearly do not even have a clear definition of what is a native application and the recent attempt to define a native application client type seems to cause more confusion than help.

While there is clearly an expectation that the specification will offer guidance to native application developers, I have yet to see any such text gaining consensus.

My suggestion is to drop this attempt, but if a new text gain consensus, I'll incorporate it.

EHL


From: Anthony Nadalin [mailto:[e-mail]]<mailto:[mailto:[e-mail]]>
Sent: Wednesday, June 15, 2011 10:10 AM
To: Eran Hammer-Lahav; Chuck Mortimore; [e-mail]<mailto:[e-mail]>
Subject: RE: Updated text for Native Apps

Since Torsten and I had the action item to propose text we will update the text based upon the list and give you back an update

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]<mailto:[mailto:[e-mail]]> On Behalf Of Eran Hammer-Lahav
Sent: Wednesday, June 15, 2011 9:33 AM
To: Chuck Mortimore; [e-mail]<mailto:[e-mail]>
Subject: Re: [OAUTH-WG] Updated text for Native Apps

Is there an updated text based on the long thread?

EHL

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]<mailto:[mailto:[e-mail]]> On Behalf Of Chuck Mortimore
Sent: Tuesday, May 31, 2011 10:37 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [OAUTH-WG] Updated text for Native Apps

Minor updates for section 9 based upon feedback from the list

-cmort

----------------


9.  Native Applications

A native application is a client which is installed and executes on the end-user's device (i.e. desktop application, native mobile application).  Native applications require special consideration related to security, platform capabilities, and overall end-user experience.  The following are examples of how native applications may utilize OAuth:

   o  Initiate an Authorization Request using an external user-agent: The native application can capture the response from the authorization server using a variety of techniques such as the use of a redirection URI identifying a custom URI scheme (registered with the operating system to invoke the native application as handler), manual copy-and-paste, running a local webserver, browser plug-ins, or by providing a redirection URI identifying a server-hosted resource under the native application's control, which in turn makes the response available to the native application.
   o  Initiate an Authorization Request using an embedded user-agent:  The native application obtains the response by directly communicating with the embedded user-agent.  Techniques include monitoring state changes emitted during URL loading, monitoring http headers, accessing the user-agent's cookie jar, etc.

When choosing between launching an external user-agent and an embedding a user-agent, native application developers should consider the following:

   o  External user-agents may improve completion rate as the end-user may already have an active session with the authorization server removing the need to re-authenticate, and provide a familiar user-agent user experience.  The end-user may also rely on extensions or add-ons to assist with authentication (e.g. password managers or 2-factor device reader).
   o  Embedded user-agents may offer an improved end-user flow, as they remove the need to switch context and open new windows.
   o  Embedded user-agents pose a security challenge because end-users are authenticating in an unidentified window without access to the visual protections offered by many user-agents.  Embedded user-agents educate end-user to trust unidentified requests for authentication (making phishing attacks easier to execute).

When choosing between implicit and authorization code grant types, the following should be considered:

   o  Native applications that use the authorization code grant type flow SHOULD do so without client password credentials, due to their inability to keep those credentials confidential.
   o  Native applications that use the implicit grant type may offer optimized performance in some scenarios due to reduced network requests
   o  The implicit grant type does not return a refresh token