You text does not mention what will be a common use case, where the native app
uses the password grant to fetch a refresh and access token. Whether or not an
app can keep a secret, it's better to have it store the token than the
username/password pair.
________________________________
From: Anthony Nadalin <[email protected]>
To: "OAuth WG ([email protected])" <[email protected]>
Sent: Tuesday, June 28, 2011 6:15 PM
Subject: [OAUTH-WG] Native Application Text
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 not returned
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
