2.1. 客户端类型 (2.1. Client Types)

2.1. 客户端类型

根据客户端与授权服务器安全地进行身份验证的能力（即维护客户端凭据机密性的能力），OAuth定义了两种客户端类型：

• 机密客户端
  能够维持其凭据机密性（如客户端执行在具有对客户端凭据有限访问权限的安全的服务器上），或者能够使用 其他方式保证客户端身份验证的安全性。
• 公开客户端
  不能够维持其凭据的机密性（如客户端执行在由资源所有者使用的设备上，例如已安装的本地应用程序或基于Web浏览器的应用），且不能通过其他方式保证客户端身份验证的安全性。 客户端类型的选择基于授权服务器的安全身份认证定义以及其对客户端凭据可接受的暴露程度。授权服务器不应该对客户端类型做假设。

客户端可以以分布式的组件集合实现，每一个组件具有不同的客户端类型和安全上下文（例如，一个同时具有机密的基于服务器的组件和公开的基于浏览器的组件的分布式客户端）。如果授权服务器不提供对这类客户端的支持，或不提供其注册方面的指导，客户端应该注册每个组件为一个单独的客户端。 本规范围绕下列客户端配置涉及：

• Web应用程序
  Web应用是一个运行在Web服务器上的机密客户端。资源所有者通过其使用的设备上的用户代理里渲染的HTML用户界面访问客户端。客户端凭据以及向客户端颁发的任何访问令牌都存储在Web服务器上且不会暴露给资源所有者或者被资源所有者可访问。
• 基于用户代理的应用
  基于用户代理的应用是一个公开客户端，客户端的代码从Web服务器下载，并在资源所有者使用的设备上的用户代理（如Web浏览器）中执行。协议数据和凭据对于资源所有者是可轻易访问的（且经常是可见的）。由于这些应用驻留在用户代理内，在请求授权时它们可以无缝地使用用户代理的功能。
• 本机应用程序
  本机应用是一个安装、运行在资源所有者使用的设备上的公开客户端。协议数据和凭据对于资源所有者是可访问的。假定包含在应用程序中的任何客户端身份认证凭据可以被提取。另一方面，动态颁发的如访问令牌或者刷新令牌等凭据可以达到可接受的保护水平。至少，这些凭据被保护不被应用可能与之交互的恶意服务器接触。在一些平台上，这些凭证可能被保护免于被驻留在相同设备上的其他应用接触。

 

2.1. Client Types

   OAuth defines two client types, based on their ability to
   authenticate securely with the authorization server (i.e., ability to
   maintain the confidentiality of their client credentials):

   confidential
      Clients capable of maintaining the confidentiality of their
      credentials (e.g., client implemented on a secure server with
      restricted access to the client credentials), or capable of secure
      client authentication using other means.

   public
      Clients incapable of maintaining the confidentiality of their
      credentials (e.g., clients executing on the device used by the
      resource owner, such as an installed native application or a web
      browser-based application), and incapable of secure client
      authentication via any other means.

   The client type designation is based on the authorization server's
   definition of secure authentication and its acceptable exposure
   levels of client credentials.  The authorization server SHOULD NOT
   make assumptions about the client type.

   A client may be implemented as a distributed set of components, each
   with a different client type and security context (e.g., a
   distributed client with both a confidential server-based component
   and a public browser-based component).  If the authorization server
   does not provide support for such clients or does not provide
   guidance with regard to their registration, the client SHOULD
   register each component as a separate client.









Hardt                        Standards Track                   [Page 14]

---

 
RFC 6749                        OAuth 2.0                   October 2012


   This specification has been designed around the following client
   profiles:

   web application
      A web application is a confidential client running on a web
      server.  Resource owners access the client via an HTML user
      interface rendered in a user-agent on the device used by the
      resource owner.  The client credentials as well as any access
      token issued to the client are stored on the web server and are
      not exposed to or accessible by the resource owner.

   user-agent-based application
      A user-agent-based application is a public client in which the
      client code is downloaded from a web server and executes within a
      user-agent (e.g., web browser) on the device used by the resource
      owner.  Protocol data and credentials are easily accessible (and
      often visible) to the resource owner.  Since such applications
      reside within the user-agent, they can make seamless use of the
      user-agent capabilities when requesting authorization.

   native application
      A native application is a public client installed and executed on
      the device used by the resource owner.  Protocol data and
      credentials are accessible to the resource owner.  It is assumed
      that any client authentication credentials included in the
      application can be extracted.  On the other hand, dynamically
      issued credentials such as access tokens or refresh tokens can
      receive an acceptable level of protection.  At a minimum, these
      credentials are protected from hostile servers with which the
      application may interact.  On some platforms, these credentials
      might be protected from other applications residing on the same
      device.