9.本机应用程序

本机应用程序

• 9.本机应用程序(9. Native Applications)

9.本机应用程序(9. Native Applications)

本机应用程序是安装和执行在资源所有者使用的设备上的客户端（例如，桌面程序，本机移动应用）。本机应用程序需要关于安全、平台能力和整体最终用户体验的特别注意事项。

授权端点需要在客户端和资源所有者用户代理之间进行交互。本机应用程序可以调用外部的用户代理，或在应用程序中嵌入用户代理。例如：

• 外部用户代理-本机应用程序可以捕获来自授权服务器的响应。它可以使用带有操作系统已注册方案的重定向URI调用客户端作为处理程序，手动复制粘贴凭据，运行本地Web服务器，安装用户代理扩展，或者通过提供重定向URI来指定客户端控制下的服务器托管资源，反过来使响应对本机应用程序可用。
• 嵌入式用户代理-通过监视资源加载过程中发生的状态变化或者访问用户代理的cookies存储，本机应用程序直接与嵌入式用户代理通信，获得响应。 当在外部或嵌入式用户代理中选择时，开发者应该考虑如下：
• 外部用户代理可能会提高完成率，因为资源所有者可能已经有了与授权服务器的活动会话，避免了重新进行身份验证的需要。它提供了熟悉的最终用户体验和功能。资源所有者可能也依赖于用户代理特性或扩展帮助他进行身份验证（例如密码管理器、两步设备读取器）
• 嵌入式用户代理可能会提供更好的可用性，因为它避免了切换上下文和打开新窗口的需要。
• 嵌入式用户代理构成了安全挑战，因为资源所有者在一个未识别的窗口中进行身份验证，无法获得在大多数外部用户代理中的可视的保护。嵌入式用户代理教育用户信任未标识身份验证请求（使钓鱼攻击更易于实施）。 当在隐式许可类型和授权码许可类型中选择时，下列应该被考虑：
• 使用授权码许可类型的本机应用程序应该这么做而不需使用用户凭据，因为本机应用程序无力保持客户端凭据的机密性。
• 当使用隐式许可类型流程时，刷新令牌不会返回，这就要求一旦访问令牌过期就要重复授权过程。

9. Native Applications

   Native applications are clients installed and executed on the device
   used by the resource owner (i.e., desktop application, native mobile
   application).  Native applications require special consideration
   related to security, platform capabilities, and overall end-user
   experience.

   The authorization endpoint requires interaction between the client
   and the resource owner's user-agent.  Native applications can invoke
   an external user-agent or embed a user-agent within the application.
   For example:

   o  External user-agent - the native application can capture the
      response from the authorization server using a redirection URI
      with a scheme registered with the operating system to invoke the
      client as the handler, manual copy-and-paste of the credentials,
      running a local web server, installing a user-agent extension, or
      by providing a redirection URI identifying a server-hosted
      resource under the client's control, which in turn makes the
      response available to the native application.

   o  Embedded user-agent - the native application obtains the response
      by directly communicating with the embedded user-agent by
      monitoring state changes emitted during the resource load, or
      accessing the user-agent's cookies storage.

   When choosing between an external or embedded user-agent, developers
   should consider the following:

   o  An external user-agent may improve completion rate, as the
      resource owner may already have an active session with the
      authorization server, removing the need to re-authenticate.  It
      provides a familiar end-user experience and functionality.  The



Hardt                        Standards Track                   [Page 52]

---

 
RFC 6749                        OAuth 2.0                   October 2012


      resource owner may also rely on user-agent features or extensions
      to assist with authentication (e.g., password manager, 2-factor
      device reader).

   o  An embedded user-agent may offer improved usability, as it removes
      the need to switch context and open new windows.

   o  An embedded user-agent poses a security challenge because resource
      owners are authenticating in an unidentified window without access
      to the visual protections found in most external user-agents.  An
      embedded user-agent educates end-users to trust unidentified
      requests for authentication (making phishing attacks easier to
      execute).

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

   o  Native applications that use the authorization code grant type
      SHOULD do so without using client credentials, due to the native
      application's inability to keep client credentials confidential.

   o  When using the implicit grant type flow, a refresh token is not
      returned, which requires repeating the authorization process once
      the access token expires.