TOC
TOC
Additionally, the rule URI-Reference is included from Uniform Resource Identifier (URI)
.
Certain security-related terms are to be understood in the sense defined in .
These terms include, but are not limited to, "attack", "authentication", "authorization",
"certificate", "confidentiality", "credential", "encryption", "identity", "sign", "signature", "trust",
"validate", and "verify".
Unless otherwise noted, all the protocol parameter names and values are case sensitive.
2. Client Registration
Before initiating the protocol, the client registers with the authorization server. The means
through which the client registers with the authorization server are beyond the scope of this
specification, but typically involve end-user interaction with an HTML registration form.
Client registration does not require a direct interaction between the client and the
authorization server. When supported by the authorization server, registration can rely on
other means for establishing trust and obtaining the required client properties (e.g.
redirection URI, client type). For example, registration can be accomplished using a self-
issued or third-party-issued assertion, or by the authorization server performing client
discovery using a trusted channel.
When registering a client, the client developer SHALL:
specify the client type as described in ,
provide its client redirection URIs as described in , and
include any other information required by the authorization server (e.g.
application name, website, description, logo image, the acceptance of legal
terms).
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.
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
[RFC3986]
[RFC4949]
Section 2.1
Section 3.1.2