Annexe A. Cas d'usage
Cette annexe décrit différentes façons dont cette spécification peut être utilisée, y compris la description de certains des choix qui peuvent devoir être faits. Certains des choix sont indépendants et peuvent être utilisés en combinaison, tandis que certains des choix sont interdépendants.
A.1. Enregistrement de client dynamique ouvert versus protégé
A.1.1. Enregistrement de client dynamique ouvert
Les serveurs d'autorisation qui prennent en charge l'enregistrement ouvert permettent aux enregistrements d'être effectués sans jeton d'accès initial. Cela permet à tous les logiciels clients de s'enregistrer auprès du serveur d'autorisation.
A.1.2. Enregistrement de client dynamique protégé
Les serveurs d'autorisation qui prennent en charge l'enregistrement protégé exigent qu'un jeton d'accès initial soit utilisé lors de la soumission de demandes d'enregistrement. Bien que la méthode par laquelle un client ou un développeur reçoit ce jeton d'accès initial et la méthode par laquelle le serveur d'autorisation valide ce jeton d'accès initial soient hors du champ d'application de cette spécification, une approche courante consiste pour le développeur à utiliser un portail de pré-enregistrement manuel sur le serveur d'autorisation qui émet un jeton d'accès initial au développeur.
A.2. Enregistrement sans ou avec des déclarations logicielles
A.2.1. Enregistrement sans déclaration logicielle
Lorsqu'une déclaration logicielle n'est pas utilisée dans la demande d'enregistrement, le serveur d'autorisation doit être disposé à utiliser les valeurs de métadonnées client sans qu'elles soient signées numériquement ou MACées (et donc attestées) par une autorité quelconque. (Notez que ce choix est indépendant du choix Ouvert versus Protégé, et qu'un jeton d'accès initial est une autre forme possible d'attestation.)
A.2.2. Enregistrement avec une déclaration logicielle
Une déclaration logicielle peut être utilisée dans une demande d'enregistrement pour fournir une attestation par une autorité pour un ensemble de valeurs de métadonnées client. Cela peut être utile lorsque le serveur d'autorisation souhaite limiter l'enregistrement au logiciel client attesté par un ensemble d'autorités ou lorsqu'il souhaite savoir que plusieurs demandes d'enregistrement font référence au même logiciel client.
A.3. Enregistrement par le client ou le développeur
A.3.1. Enregistrement par le client
Dans certains cas d'usage, le logiciel client s'enregistrera dynamiquement auprès d'un serveur d'autorisation pour obtenir un identifiant client et d'autres informations nécessaires pour interagir avec le serveur d'autorisation. Dans ce cas, aucun identifiant client pour le serveur d'autorisation n'est emballé avec le logiciel client.
A.3.2. Enregistrement par le développeur
Dans certains cas, le développeur (ou le logiciel de développement utilisé par le développeur) pré-enregistrera le logiciel client auprès du serveur d'autorisation ou d'un ensemble de serveurs d'autorisation. Dans ce cas, la ou les valeurs d'identifiant client pour le ou les serveurs d'autorisation peuvent être emballées avec le logiciel client.
A.4. ID client par instance de client ou par logiciel client
A.4.1. ID client par instance de logiciel client
Dans certains cas, chaque instance déployée d'un logiciel client s'enregistrera dynamiquement et obtiendra des valeurs d'identifiant client distinctes. Cela peut être avantageux, par exemple, si le flux de code est utilisé, car cela permet également à chaque instance client d'avoir son propre secret client. Cela peut être utile pour les clients natifs, qui ne peuvent pas maintenir le secret d'une valeur de secret client emballée avec le logiciel, mais qui peuvent être en mesure de maintenir le secret d'un secret client par instance.
A.4.2. ID client partagé entre toutes les instances de logiciel client
Dans certains cas, chaque instance déployée d'un logiciel client partagera une valeur d'identifiant client commune. Par exemple, c'est souvent le cas pour les clients dans le navigateur utilisant le flux implicite, lorsqu'aucun secret client n'est impliqué. Des serveurs d'autorisation particuliers pourraient choisir, par exemple, de maintenir un mappage entre les valeurs de déclaration logicielle et les valeurs d'identifiant client, et de renvoyer la même valeur d'identifiant client pour toutes les demandes d'enregistrement pour un logiciel particulier. Les circonstances dans lesquelles un serveur d'autorisation le ferait, et les caractéristiques spécifiques de la déclaration logicielle requises dans ce cas, sont hors du champ d'application de cette spécification.
A.5. Enregistrement avec ou sans état
A.5.1. Enregistrement de client avec état
Dans certains cas, les serveurs d'autorisation maintiendront l'état des clients enregistrés, indexant généralement cet état à l'aide de la valeur d'identifiant client. Cet état comprendrait généralement les valeurs de métadonnées client associées à l'enregistrement du client, et éventuellement d'autres états spécifiques à l'implémentation du serveur d'autorisation. Lorsque l'enregistrement avec état est utilisé, les opérations de récupération et/ou de mise à jour de cet état peuvent être prises en charge. Un ensemble possible d'opérations sur les enregistrements avec état est décrit dans [RFC7592].
A.5.2. Enregistrement de client sans état
Dans certains cas, les serveurs d'autorisation seront implémentés de manière à leur permettre de ne pas maintenir d'état local sur les clients enregistrés. Un moyen de le faire consiste à encoder tout l'état d'enregistrement dans la valeur d'identifiant client renvoyée, et éventuellement à chiffrer l'état au serveur d'autorisation pour maintenir la confidentialité et l'intégrité de l'état.