2.3. Error Response (Réponse d'erreur)

2.3. Error Response (Réponse d'erreur)

Le serveur d'autorisation renvoie une réponse d'erreur au même format que pour les réponses d'erreur du point de terminaison de jeton (section 5.2 de [RFC6749]), en utilisant le code d'erreur approprié de celle-ci ou de la section 4.1.2.1 de [RFC6749]. Lorsque la section 4.1.2.1 de [RFC6749] interdit la redirection automatique avec une erreur vers le client demandeur et ne définit donc pas de code (par ex. échec dû à un URI de redirection manquant, invalide ou non concordant), le code invalid_request peut servir de défaut. Les codes définis par une extension OAuth peuvent aussi être utilisés lorsque cette extension intervient dans le traitement initial de la requête d'autorisation poussée. Comme ce traitement initial n'implique pas l'interaction avec le propriétaire de ressource, les codes liés à l'interaction utilisateur, tels que consent_required [OIDC], ne sont jamais renvoyés.

Si le client doit utiliser des Request Objects signés, par politique du serveur ou du client (voir [RFC9101], section 10.5), le serveur d'autorisation DOIT n'accepter que les requêtes conformes à la section 3 et DOIT refuser toute autre requête avec le code d'état HTTP 400 et le code d'erreur invalid_request.

En outre, le point de terminaison PAR peut utiliser les codes d'état HTTP suivants :

405 : si la requête n'utilisait pas POST, réponse HTTP 405 (Method Not Allowed).

413 : si la taille dépasse la limite supérieure autorisée par le serveur, réponse HTTP 413 (Payload Too Large).

429 : si le nombre de requêtes d'un client sur une période dépasse la limite du serveur, réponse HTTP 429 (Too Many Requests).

Exemple d'erreur :

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-cache, no-store

{
  "error": "invalid_request",
  "error_description":
    "The redirect_uri is not valid for the given client"
}