2. Enregistrement du client (Client Registration)
Avant de commencer le protocole, le client s'enregistre auprès du serveur d'autorisation (Authorization Server). La manière dont le client s'enregistre auprès du serveur d'autorisation dépasse le cadre de cette spécification, mais implique généralement une interaction de l'utilisateur final avec un formulaire d'enregistrement HTML.
L'enregistrement du client ne nécessite pas (MUST NOT) d'interaction directe entre le client et le serveur d'autorisation. Lorsqu'elle est prise en charge par le serveur d'autorisation, l'enregistrement peut s'appuyer sur d'autres moyens pour établir une relation de confiance et obtenir les propriétés du client (telles que l'URI de redirection, le type de client). Par exemple, l'enregistrement peut être effectué à l'aide d'assertions auto-émises ou émises par un tiers, ou par le serveur d'autorisation effectuant une découverte de client à l'aide d'un canal de confiance.
Lors de l'enregistrement d'un client, le développeur de client devrait (SHOULD) :
- Spécifier le type de client tel que décrit dans la section 2.1
- Fournir son URI de redirection tel que décrit dans la section 3.1.2
- Inclure toute autre information requise par le serveur d'autorisation (par exemple, nom de l'application, site Web, description, image de logo, acceptation des conditions légales)
2.1. Types de client (Client Types)
En fonction de la capacité du client à s'authentifier de manière sécurisée auprès du serveur d'autorisation (c'est-à-dire la capacité à maintenir la confidentialité de ses informations d'identification), OAuth définit deux types de client :
Client confidentiel (Confidential Client)
Un client capable de maintenir la confidentialité de ses informations d'identification (par exemple, le client s'exécute sur un serveur sécurisé avec un accès restreint aux informations d'identification du client), ou capable d'assurer l'authentification sécurisée du client par d'autres moyens.
Client public (Public Client)
Un client incapable de maintenir la confidentialité de ses informations d'identification (par exemple, le client s'exécute sur l'appareil utilisé par le propriétaire de ressource, comme une application native installée ou une application basée sur un navigateur Web), et incapable d'assurer l'authentification sécurisée du client par d'autres moyens.
Le choix du type de client est basé sur les définitions d'authentification de sécurité du serveur d'autorisation et son niveau d'exposition acceptable des informations d'identification du client. Le serveur d'autorisation ne devrait pas (SHOULD NOT) faire d'hypothèses sur le type de client.
Un client peut être implémenté comme un ensemble de composants distribués, chacun avec un type de client et un contexte de sécurité différents (par exemple, un client distribué avec à la fois un composant confidentiel basé sur un serveur et un composant public basé sur un navigateur). Si le serveur d'autorisation ne prend pas en charge ces clients ou ne fournit pas de conseils concernant leur enregistrement, le client devrait (SHOULD) enregistrer chaque composant séparément en tant que client distinct.
Cette spécification a été conçue autour des profils de client suivants :
Application Web (Web Application)
Une application Web est un client confidentiel s'exécutant sur un serveur Web. Le propriétaire de ressource accède au client via une interface utilisateur HTML rendue dans un agent utilisateur sur l'appareil utilisé par le propriétaire de ressource. Les informations d'identification du client ainsi que tout jeton d'accès émis au client sont stockés sur le serveur Web et ne sont pas exposés ou accessibles au propriétaire de ressource.
Application basée sur un agent utilisateur (User-Agent-Based Application)
Une application basée sur un agent utilisateur est un client public dans lequel le code du client est téléchargé depuis un serveur Web et exécuté dans un agent utilisateur (par exemple, un navigateur Web) sur l'appareil utilisé par le propriétaire de ressource. Les données de protocole et les informations d'identification sont facilement accessibles (et souvent visibles) au propriétaire de ressource. Étant donné que ces applications résident dans l'agent utilisateur, elles peuvent utiliser de manière transparente les capacités de l'agent utilisateur lors de la demande d'autorisation.
Application native (Native Application)
Une application native est un client public installé et exécuté sur l'appareil utilisé par le propriétaire de ressource. Les données de protocole et les informations d'identification sont accessibles au propriétaire de ressource. On suppose que toutes les informations d'authentification du client incluses dans l'application peuvent être extraites. D'autre part, les informations d'identification émises dynamiquement telles que les jetons d'accès ou les jetons de rafraîchissement (Refresh Token) peuvent atteindre un niveau de protection acceptable. Au minimum, ces informations d'identification sont protégées contre les serveurs malveillants avec lesquels l'application peut interagir. Sur certaines plateformes, ces informations d'identification peuvent être protégées contre d'autres applications résidant sur le même appareil.
2.2. Identifiant du client (Client Identifier)
Le serveur d'autorisation émet à un client enregistré un identifiant de client (Client Identifier) — une chaîne unique représentant les informations d'enregistrement fournies par le client. L'identifiant du client n'est pas un secret ; il est exposé au propriétaire de ressource et ne doit pas (MUST NOT) être utilisé seul pour l'authentification du client. L'identifiant du client est unique au serveur d'autorisation.
La taille de la chaîne d'identifiant du client n'est pas définie par cette spécification. Le client devrait (SHOULD) éviter de faire des hypothèses sur la taille de l'identifiant. Le serveur d'autorisation devrait (SHOULD) documenter la taille de tout identifiant qu'il émet.
2.3. Authentification du client (Client Authentication)
Si le type de client est confidentiel, le client et le serveur d'autorisation établissent une méthode d'authentification du client appropriée aux exigences de sécurité du serveur d'autorisation. Le serveur d'autorisation peut (MAY) accepter toute forme d'authentification du client répondant à ses exigences de sécurité.
Les clients confidentiels reçoivent généralement (ou établissent) un ensemble d'informations d'identification du client à utiliser pour l'authentification auprès du serveur d'autorisation (par exemple, mot de passe, paire de clés publique/privée). Le serveur d'autorisation peut (MAY) établir une méthode d'authentification du client avec les clients publics. Cependant, le serveur d'autorisation ne doit pas (MUST NOT) s'appuyer sur l'authentification du client public dans le but d'identifier le client.
Le client ne doit pas (MUST NOT) utiliser plus d'une méthode d'authentification dans chaque demande.
2.3.1. Mot de passe du client (Client Password)
Les clients possédant un mot de passe client peuvent (MAY) utiliser le schéma d'authentification HTTP Basic tel que défini dans <RFC2617> pour s'authentifier auprès du serveur d'autorisation. L'identifiant du client est encodé à l'aide de l'algorithme d'encodage application/x-www-form-urlencoded tel que défini dans l'Annexe B, et la valeur encodée est utilisée comme nom d'utilisateur ; le mot de passe du client est encodé à l'aide du même algorithme et utilisé comme mot de passe. Le serveur d'autorisation doit (MUST) prendre en charge le schéma d'authentification HTTP Basic pour l'authentification des clients ayant reçu un mot de passe client.
Par exemple (sauts de ligne supplémentaires uniquement à des fins d'affichage) :
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
Alternativement, le serveur d'autorisation peut (MAY) prendre en charge l'inclusion des informations d'identification du client dans le corps de la demande en utilisant les paramètres suivants :
client_id
Requis (REQUIRED). L'identifiant du client émis au client pendant le processus d'enregistrement décrit dans la section 2.2.
client_secret
Requis (REQUIRED). Le secret du client. Le client peut (MAY) omettre ce paramètre si le secret du client est une chaîne vide.
L'inclusion des informations d'identification du client dans le corps de la demande en utilisant ces deux paramètres n'est pas recommandée (NOT RECOMMENDED) et devrait (SHOULD) être limitée aux clients incapables d'utiliser directement le schéma d'authentification HTTP Basic (ou un autre schéma d'authentification HTTP basé sur un mot de passe). Les paramètres ne peuvent être transmis que dans le corps de la demande et ne doivent pas (MUST NOT) être inclus dans l'URI de la demande.
Le serveur d'autorisation doit (MUST) exiger l'utilisation de TLS tel que décrit dans la section 1.6 lors de l'envoi de demandes utilisant l'authentification par mot de passe.
Étant donné que cette méthode d'authentification du client implique un mot de passe, le serveur d'autorisation doit (MUST) protéger tous les points de terminaison utilisant ce mot de passe contre les attaques par force brute.
2.3.2. Autres méthodes d'authentification (Other Authentication Methods)
Le serveur d'autorisation peut (MAY) prendre en charge tout schéma d'authentification HTTP approprié répondant à ses exigences de sécurité. Lors de l'utilisation d'autres méthodes d'authentification, le serveur d'autorisation doit (MUST) définir un mappage entre l'identifiant du client (l'enregistrement) et le schéma d'authentification.
2.4. Clients non enregistrés (Unregistered Clients)
Cette spécification ne prévoit pas l'utilisation de clients non enregistrés. Cependant, le serveur d'autorisation peut (MAY) prendre en charge ces clients.
Lors de l'utilisation de clients non enregistrés, l'identifiant du client est obtenu d'une autre manière non définie par cette spécification. Le serveur d'autorisation devrait (SHOULD) documenter les exigences et les restrictions relatives à l'utilisation de clients non enregistrés.