Oauth - Client (App)

> Software Security > (Authentication|Access control|Identification) - AuthN > Oauth 2.0 - Authorization framework

1 - About

client is one of the 4 roles of the Oauth specification.

In its most basic form, it's a web site used by a end-user.

In more details, it's is a (first-party or third party service application making protected resource requests on behalf of the resource owner (end-user) and with its authorization.

Advertising

3 - Example

An end-user (resource owner) can grant a printing service (the client) access to her protected photos stored at a photo-sharing service (resource server).

4 - Implementation

The term client does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).

5 - Properties

5.1 - Identifier

After the registration, the authorization server issues the registered client a client identifier – a unique string representing the registration information provided by the client.

The client identifier is not a secret; it is exposed to the resource owner and MUST NOT be used alone for client authentication. The client identifier is unique to the authorization server.

The client identifier string size is left undefined by the Oauth specification.

The client should avoid making assumptions about the identifier size.

The authorization server SHOULD document the size of any identifier it issues.

5.2 - Type

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):

Type Confidential credentials Client Authentication eg Profiles
confidential (private) Yes secure - client implemented on a secure server with restricted access to the client credentials
- or capable of secure client authentication using other means
web server based application
public No Unsecure Clients executing on the device used by the resource owner,
and incapable of secure client authentication via any other means.
- an installed native application
- or a web browser-based application
Advertising

5.3 - Profile

This specification has been designed around the following client profiles:

6 - Management

6.1 - Registration

Before initiating any protocol, the client registers with the authorization server (typically through a form) to:

  • establish trust
  • obtain 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
  • include any other information required by the authorization server (e.g., application name, website, description, logo image, the acceptance of legal terms).

The authorization server MUST require the following clients to register their redirection endpoint:

The authorization server SHOULD require all clients to register their redirection endpoint prior to utilizing the authorization endpoint.

Lack of a redirection URI registration requirement can enable an attacker to use the authorization endpoint as an open redirector as described in Section 10.15.

Doc: Registration Requirements

Advertising

6.2 - Authentication

7 - Documentation / Reference

security/auth/oauth/client.txt · Last modified: 2019/05/11 17:41 by gerardnico