1. Introduction

Pour qu'un client OAuth 2.0 [RFC6749] puisse utiliser un serveur d'autorisation OAuth 2.0, le client a besoin d'informations spécifiques pour interagir avec le serveur, notamment un identifiant client OAuth 2.0 à utiliser sur ce serveur. Cette spécification décrit comment un client OAuth 2.0 peut être enregistré dynamiquement auprès d'un serveur d'autorisation pour obtenir ces informations.

Dans le cadre du processus d'enregistrement, cette spécification définit également un mécanisme permettant au client de présenter au serveur d'autorisation un ensemble de métadonnées, tel qu'un ensemble d'URI de redirection valides. Ces métadonnées peuvent être communiquées de manière auto-déclarée ou sous la forme d'un ensemble de métadonnées appelé déclaration logicielle (software statement), qui est signée numériquement ou protégée par un code d'authentification de message (MAC) ; dans le cas d'une déclaration logicielle, l'émetteur se porte garant de la validité des données concernant le client.

Traditionnellement, l'enregistrement d'un client auprès d'un serveur d'autorisation est effectué manuellement. Les mécanismes définis dans cette spécification peuvent être utilisés soit pour qu'un client s'enregistre dynamiquement auprès de serveurs d'autorisation, soit pour qu'un développeur de client enregistre le client par programmation auprès de serveurs d'autorisation. Plusieurs applications utilisant OAuth 2.0 ont précédemment développé des mécanismes pour accomplir de tels enregistrements. Cette spécification généralise les mécanismes d'enregistrement définis par "OpenID Connect Dynamic Client Registration 1.0" [OpenID.Registration] et utilisés par "User Managed Access (UMA) Profile of OAuth 2.0" [UMA-Core] d'une manière qui est compatible avec les deux, tout en étant applicable à un ensemble plus large de cas d'utilisation OAuth 2.0.

1.1. Conventions de notation

Les mots clés « MUST », « MUST NOT », « REQUIRED », « SHALL », « SHALL NOT », « SHOULD », « SHOULD NOT », « RECOMMENDED », « MAY » et « OPTIONAL » dans ce document doivent être interprétés comme décrit dans la [RFC2119].

Sauf indication contraire, tous les noms et valeurs de paramètres de protocole sont sensibles à la casse.

1.2. Terminologie

Cette spécification utilise les termes "jeton d'accès", "code d'autorisation", "point de terminaison d'autorisation", "autorisation", "serveur d'autorisation", "client", "identifiant client", "secret client", "type d'autorisation", "ressource protégée", "URI de redirection", "jeton d'actualisation", "propriétaire de la ressource", "serveur de ressources", "type de réponse" et "point de terminaison de jeton" définis par OAuth 2.0 [RFC6749] et utilise le terme "Revendication (Claim)" défini par JSON Web Token (JWT) [RFC7519].

Cette spécification définit les termes suivants :

Client Software (Logiciel client) Logiciel implémentant un client OAuth 2.0.

Client Instance (Instance client) Une instance déployée d'un logiciel client.

Client Developer (Développeur client) La personne ou l'organisation qui crée un progiciel client et le prépare pour la distribution. Au moment où le client est créé, le développeur n'est souvent pas au courant de l'identité des organisations de fournisseurs de services de déploiement. Les développeurs de clients devront utiliser l'enregistrement dynamique lorsqu'ils ne sont pas en mesure de prédire certains aspects du logiciel, tels que les URL de déploiement, au moment de la compilation. Par exemple, cela peut se produire lorsque l'éditeur de l'API logicielle et l'organisation de déploiement ne sont pas les mêmes.

Client Registration Endpoint (Point de terminaison d'enregistrement client) Point de terminaison OAuth 2.0 par lequel un client peut être enregistré auprès d'un serveur d'autorisation. Les moyens par lesquels l'URL de ce point de terminaison est obtenue sont hors du champ d'application de cette spécification.

Initial Access Token (Jeton d'accès initial) Jeton d'accès OAuth 2.0 émis optionnellement par un serveur d'autorisation à un développeur ou à un client et utilisé pour autoriser les appels au point de terminaison d'enregistrement client. Le type et le format de ce jeton sont probablement spécifiques au service et hors du champ d'application de cette spécification. Les moyens par lesquels le serveur d'autorisation émet ce jeton ainsi que les moyens par lesquels le point de terminaison d'enregistrement valide ce jeton sont hors du champ d'application de cette spécification. L'utilisation d'un jeton d'accès initial est requise lorsque le serveur d'autorisation limite les parties qui peuvent enregistrer un client.

Deployment Organization (Organisation de déploiement) Un domaine de sécurité administratif sous lequel une API logicielle (service) est déployée et protégée par un cadre OAuth 2.0. Dans certains scénarios OAuth, l'organisation de déploiement et l'éditeur de l'API logicielle sont les mêmes. Dans ces cas, l'organisation de déploiement aura souvent une relation étroite avec les développeurs de logiciels clients. Dans de nombreux autres cas, le définisseur du service peut être un éditeur tiers indépendant ou une organisation de normalisation. Lorsqu'il travaille sur une spécification publiée pour une API, le développeur de logiciel client n'est pas en mesure d'avoir une relation préalable avec les organisations de déploiement potentiellement nombreuses déployant l'API logicielle (service).

Software API Deployment (Déploiement d'API logicielle) Une instance déployée d'une API logicielle qui est protégée par OAuth 2.0 (une ressource protégée) dans un domaine d'organisation de déploiement particulier. Pour toute API logicielle particulière, il peut y avoir un ou plusieurs déploiements. Un déploiement d'API logicielle a généralement un serveur d'autorisation OAuth 2.0 associé ainsi qu'un point de terminaison d'enregistrement client. Les moyens par lesquels les points de terminaison sont obtenus sont hors du champ d'application de cette spécification.

Software API Publisher (Éditeur d'API logicielle) L'organisation qui définit une API accessible via le Web particulière qui peut être déployée dans un ou plusieurs environnements de déploiement. Un éditeur peut être n'importe quel organisme de normalisation, organisation commerciale, publique, privée ou open source qui est responsable de la publication et de la distribution de logiciels et de spécifications d'API qui peuvent être protégés via OAuth 2.0. Dans certains cas, un éditeur d'API logicielle et un développeur client peuvent être la même organisation. Au moment de la publication d'une API accessible via le Web, l'éditeur de logiciel n'a souvent pas de relation préalable avec les organisations de déploiement.

Software Statement (Déclaration logicielle) Un JSON Web Token (JWT) [RFC7519] signé numériquement ou MACé qui affirme des valeurs de métadonnées concernant le logiciel client. Dans certains cas, une déclaration logicielle sera émise directement par le développeur client. Dans d'autres cas, une déclaration logicielle sera émise par une organisation tierce pour être utilisée par le développeur client. Dans les deux cas, la relation de confiance que le serveur d'autorisation entretient avec l'émetteur de la déclaration logicielle est destinée à être utilisée comme une entrée pour l'évaluation de l'acceptation de la demande d'enregistrement. Une déclaration logicielle peut être présentée à un serveur d'autorisation dans le cadre d'une demande d'enregistrement client.

1.3. Flux du protocole

    +--------(A)- Jeton d'accès initial (OPTIONNEL)
    |
    |   +----(B)- Déclaration logicielle (OPTIONNEL)
    |   |
    v   v
+-----------+                                      +---------------+
|           |--(C)- Demande d'enregistrement client->|    Client     |
| Client ou |                                      | Enregistrement|
| Développeur|<-(D)- Réponse d'information client ---|     Point de  |
|           |        ou Réponse d'erreur client    |  terminaison  |
+-----------+                                      +---------------+

Figure 1 : Flux abstrait d'enregistrement dynamique de client

Le flux abstrait d'enregistrement dynamique client OAuth 2.0 illustré à la Figure 1 décrit l'interaction entre le client ou le développeur et le point de terminaison défini dans cette spécification. Cette figure ne montre pas les conditions d'erreur. Ce flux comprend les étapes suivantes :

(A) Optionnellement, un jeton d'accès initial donnant accès au point de terminaison d'enregistrement client est émis au client ou au développeur. La méthode par laquelle le jeton d'accès initial est émis au client ou au développeur est hors du champ d'application de cette spécification.

(B) Optionnellement, une déclaration logicielle à utiliser avec le point de terminaison d'enregistrement client est émise au client ou au développeur. La méthode par laquelle la déclaration logicielle est émise au client ou au développeur est hors du champ d'application de cette spécification.

(C) Le client ou le développeur appelle le point de terminaison d'enregistrement client avec les métadonnées d'enregistrement souhaitées par le client, incluant optionnellement le jeton d'accès initial de (A) si l'un est requis par le serveur d'autorisation.

(D) Le serveur d'autorisation enregistre le client et renvoie :

  *  les métadonnées enregistrées du client,

  *  un identifiant client qui est unique au niveau du serveur, et

  *  un ensemble d'identifiants client tels qu'un secret client, si applicable pour ce client.

Des exemples de différentes configurations et utilisations sont inclus dans l'Annexe A.