Aller au contenu principal

8. Extensibilité (Extensibility)

8.1. Définition des types de jetons d'accès (Defining Access Token Types)​

Les types de jetons d'accès (Access Token Types) peuvent être définis de deux manières : enregistrés dans le registre des types de jetons d'accès (en suivant les procédures de la section 11.1), ou en utilisant un URI absolu unique comme nom.

Les types utilisant un nom d'URI devraient (SHOULD) être limités aux implémentations spécifiques au fournisseur qui ne sont pas couramment applicables et qui sont spécifiques aux détails d'implémentation du serveur de ressources (Resource Server) où ils sont utilisés.

Tous les autres types doivent (MUST) être enregistrés. Les noms de type doivent (MUST) être conformes à l'ABNF type-name. Si la définition du type inclut un nouveau schéma d'authentification HTTP, le nom du type devrait (SHOULD) être identique au nom du schéma d'authentification HTTP (tel que défini par [RFC2617]). Le type de jeton « example » est réservé pour une utilisation dans les exemples.

type-name  = 1*name-char
name-char  = "-" / "." / "_" / DIGIT / ALPHA

8.2. Définition de nouveaux paramètres de point de terminaison (Defining New Endpoint Parameters)​

Les nouveaux paramètres de requête ou de réponse à utiliser avec le point de terminaison d'autorisation (Authorization Endpoint) ou le point de terminaison de jeton (Token Endpoint) sont définis et enregistrés dans le registre des paramètres OAuth en suivant la procédure de la section 11.2.

Les noms de paramètre doivent (MUST) être conformes à l'ABNF param-name, et la syntaxe des valeurs de paramètre doit (MUST) être bien définie (par exemple, en utilisant ABNF ou une référence à la syntaxe d'un paramètre existant).

param-name  = 1*name-char
name-char   = "-" / "." / "_" / DIGIT / ALPHA

Les extensions de paramètres spécifiques au fournisseur non enregistrées qui ne sont pas couramment applicables et qui sont spécifiques aux détails d'implémentation du serveur d'autorisation (Authorization Server) où elles sont utilisées devraient (SHOULD) utiliser un préfixe spécifique au fournisseur qui n'est pas susceptible d'entrer en conflit avec d'autres valeurs enregistrées (par exemple, commencer par « companyname_ »).

8.3. Définition de nouveaux types d'autorisation (Defining New Authorization Grant Types)​

Les nouveaux types d'autorisation (Authorization Grant Types) peuvent être définis en leur attribuant un URI absolu unique à utiliser avec le paramètre « grant_type ». Si le type d'autorisation d'extension nécessite des paramètres de point de terminaison de jeton supplémentaires, ils doivent (MUST) être enregistrés dans le registre des paramètres OAuth comme décrit dans la section 11.2.

8.4. Définition de nouveaux types de réponse de point de terminaison d'autorisation (Defining New Authorization Endpoint Response Types)​

Les nouveaux types de réponse à utiliser avec le point de terminaison d'autorisation sont définis et enregistrés dans le registre des types de réponse de point de terminaison d'autorisation en suivant la procédure de la section 11.3. Les noms de type de réponse doivent (MUST) être conformes à l'ABNF response-type.

response-type  = response-name *( SP response-name )
response-name  = 1*response-char
response-char  = "_" / DIGIT / ALPHA

Si un type de réponse contient un ou plusieurs caractères d'espacement (%x20), il est comparé comme une liste de valeurs délimitées par des espaces dans laquelle l'ordre des valeurs n'a pas d'importance. Un seul ordre de valeurs peut être enregistré, qui couvre tous les autres arrangements du même ensemble de valeurs.

Par exemple, le type de réponse « token code » n'est pas défini par cette spécification. Cependant, une extension peut définir et enregistrer le type de réponse « token code ». Une fois enregistré, la même combinaison ne peut pas être enregistrée comme « code token », mais les deux valeurs peuvent être utilisées pour désigner le même type de réponse.

8.5. Définition de codes d'erreur supplémentaires (Defining Additional Error Codes)​

Dans les cas où les extensions de protocole (c'est-à-dire les types de jetons d'accès, les paramètres d'extension ou les types d'autorisation d'extension) nécessitent l'utilisation de codes d'erreur supplémentaires avec la réponse d'erreur d'autorisation par code (section 4.1.2.1), la réponse d'erreur d'autorisation implicite (section 4.2.2.1), la réponse d'erreur de jeton (section 5.2) ou la réponse d'erreur d'accès aux ressources (section 7.2), de tels codes d'erreur peuvent (MAY) être définis.

Les codes d'erreur d'extension doivent (MUST) être enregistrés (en suivant les procédures de la section 11.4) si l'extension avec laquelle ils sont utilisés est un type de jeton d'accès enregistré, un paramètre de point de terminaison enregistré ou un type d'autorisation d'extension. Les codes d'erreur utilisés avec des extensions non enregistrées peuvent (MAY) être enregistrés.

Les codes d'erreur doivent (MUST) être conformes à l'ABNF error et devraient (SHOULD) être préfixés par un nom d'identification lorsque cela est possible. Par exemple, une erreur identifiant une valeur invalide définie sur le paramètre d'extension « example » devrait (SHOULD) être nommée « example_invalid ».

error      = 1*error-char
error-char = %x20-21 / %x23-5B / %x5D-7E
Dernière mise à jour le