This assumes we support the authorization code grant type without client authentication. See http://www.ietf.org/mail-archive/web/oauth/current/msg06816.html and many other contributions on the same topic
Regards Mark oauth-boun...@ietf.org wrote on 29/06/2011 02:15:10: > From: > > Anthony Nadalin <tony...@microsoft.com> > > To: > > "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> > > Date: > > 29/06/2011 02:15 > > Subject: > > [OAUTH-WG] Native Application Text > > Sent by: > > oauth-boun...@ietf.org > > 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, etc.). Native applications may 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 the various methods for redirection including a 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 > embedded 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 and functionality. 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 found on by many of the external 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 using client password credentials, due to > the native application’s inability to keep those credentials secure. > o When using the implicit grant type flow a refresh token is notreturned > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
