Aller au contenu principal

5. Émission d'un jeton d'accès (Issuing an Access Token)

Si la demande de jeton d'accès est valide et autorisée, le serveur d'autorisation (Authorization Server) émet un jeton d'accès (Access Token) et un jeton de rafraîchissement (Refresh Token) facultatif comme décrit dans la section 5.1. Si la demande a échoué l'authentification du client ou est invalide, le serveur d'autorisation renvoie une réponse d'erreur comme décrit dans la section 5.2.

5.1. Réponse réussie (Successful Response)​

Le serveur d'autorisation émet un jeton d'accès (Access Token) et un jeton de rafraîchissement (Refresh Token) facultatif, et construit la réponse en ajoutant les paramètres suivants au corps de l'entité de la réponse HTTP avec un code d'état 200 (OK).

access_token
Requis (REQUIRED). Le jeton d'accès émis par le serveur d'autorisation.

token_type
Requis (REQUIRED). Le type du jeton émis tel que décrit dans la section 7.1. La valeur est insensible à la casse.

expires_in
Recommandé (RECOMMENDED). La durée de vie en secondes du jeton d'accès. Par exemple, la valeur « 3600 » indique que le jeton d'accès expirera dans une heure à partir du moment où la réponse a été générée. Si omis, le serveur d'autorisation devrait (SHOULD) fournir le délai d'expiration via d'autres moyens ou documenter la valeur par défaut.

refresh_token
Facultatif (OPTIONAL). Le jeton de rafraîchissement (Refresh Token), qui peut être utilisé pour obtenir de nouveaux jetons d'accès en utilisant la même autorisation (Authorization Grant) comme décrit dans la section 6.

scope
Facultatif (OPTIONAL), si identique à la portée demandée par le client; sinon, requis (REQUIRED). La portée du jeton d'accès telle que décrite dans la section 3.3.

Les paramètres sont inclus dans le corps de l'entité de la réponse HTTP en utilisant le type de média application/json tel que défini par [RFC4627]. Les paramètres sont sérialisés dans une structure JavaScript Object Notation (JSON) en ajoutant chaque paramètre au niveau de structure le plus élevé. Les noms de paramètres et les valeurs de chaîne sont inclus en tant que chaînes JSON. Les valeurs numériques sont incluses en tant que nombres JSON. L'ordre des paramètres n'a pas d'importance et peut varier.

Le serveur d'autorisation doit (MUST) inclure le champ d'en-tête de réponse HTTP « Cache-Control » [RFC2616] avec une valeur de « no-store » dans toute réponse contenant des jetons, des informations d'identification ou d'autres informations sensibles, ainsi que le champ d'en-tête de réponse « Pragma » [RFC2616] avec une valeur de « no-cache ».

Par exemple :

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"example",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
  "example_parameter":"example_value"
}

Le client doit (MUST) ignorer les noms de valeur non reconnus dans la réponse. Les tailles des jetons et autres valeurs reçues du serveur d'autorisation ne sont pas définies. Le client devrait (SHOULD) éviter de faire des suppositions sur les tailles des valeurs. Le serveur d'autorisation devrait (SHOULD) documenter la taille de toute valeur qu'il émet.

5.2. Réponse d'erreur (Error Response)​

Le serveur d'autorisation répond avec un code d'état HTTP 400 (Bad Request) (sauf indication contraire) et inclut les paramètres suivants avec la réponse.

error
Requis (REQUIRED). Un code d'erreur ASCII [USASCII] unique. L'un des suivants :

  • invalid_request - La demande manque un paramètre requis, inclut une valeur de paramètre non prise en charge (autre que le type d'autorisation), répète un paramètre, inclut plusieurs informations d'identification, utilise plus d'un mécanisme pour authentifier le client ou est autrement mal formée.

  • invalid_client - L'authentification du client a échoué (par exemple, client inconnu, aucune authentification de client incluse ou méthode d'authentification non prise en charge). Le serveur d'autorisation peut (MAY) renvoyer un code d'état HTTP 401 (Unauthorized) pour indiquer les schémas d'authentification HTTP pris en charge par le client. Si le client a tenté de s'authentifier via le schéma d'authentification HTTP Basic, le serveur d'autorisation ne doit pas (MUST NOT) renvoyer un code d'état HTTP 401 (Unauthorized).

  • invalid_grant - L'autorisation (Authorization Grant) fournie (par exemple, code d'autorisation (Authorization Code), informations d'identification du propriétaire de ressource (Resource Owner Credentials)) ou le jeton de rafraîchissement (Refresh Token) est invalide, expiré, révoqué, ne correspond pas à l'URI de redirection utilisé dans la demande d'autorisation ou a été émis pour un autre client.

  • unauthorized_client - Le client authentifié n'est pas autorisé à utiliser ce type d'autorisation (Authorization Grant Type).

  • unsupported_grant_type - Le type d'autorisation n'est pas pris en charge par le serveur d'autorisation.

  • invalid_scope - La portée demandée est invalide, inconnue, mal formée ou dépasse la portée accordée par le propriétaire de ressource.

Les valeurs de paramètre ne doivent pas (MUST NOT) inclure des caractères en dehors de l'ensemble %x20-21 / %x23-5B / %x5D-7E.

error_description
Facultatif (OPTIONAL). Texte ASCII [USASCII] lisible par l'homme fournissant des informations supplémentaires. Utilisé pour aider le développeur client à comprendre l'erreur. Les valeurs de paramètre ne doivent pas (MUST NOT) inclure des caractères en dehors de l'ensemble %x20-21 / %x23-5B / %x5D-7E.

error_uri
Facultatif (OPTIONAL). Un URI identifiant une page Web lisible par l'homme avec des informations sur l'erreur. Utilisé pour fournir au développeur client des informations supplémentaires sur l'erreur. Les valeurs de paramètre doivent (MUST) être conformes à la syntaxe de référence URI définie dans [RFC3986] section 2 et ne doivent pas (MUST NOT) inclure des caractères en dehors de l'ensemble %x21 / %x23-5B / %x5D-7E.

Les paramètres sont inclus dans le corps de l'entité de la réponse HTTP en utilisant le type de média application/json tel que défini par [RFC4627]. Les paramètres sont sérialisés dans une structure JavaScript Object Notation (JSON) en ajoutant chaque paramètre au niveau de structure le plus élevé. Les noms de paramètres et les valeurs de chaîne sont inclus en tant que chaînes JSON. Les valeurs numériques sont incluses en tant que nombres JSON. L'ordre des paramètres n'a pas d'importance et peut varier.

Par exemple :

HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "error":"invalid_request"
}
Dernière mise à jour le