2.3. Error Response (Risposta di errore)

2.3. Error Response (Risposta di errore)

Il server di autorizzazione restituisce errori nello stesso formato dell’endpoint del token (sezione 5.2 di [RFC6749]) e usa i codici appropriati da lì o dalla sezione 4.1.2.1 di [RFC6749]. Quando la sezione 4.1.2.1 di [RFC6749] non prevede reindirizzamento automatico con errore e non definisce un codice (ad es. redirect URI mancante, non valida o non corrispondente), si PUÒ usare invalid_request come predefinito. Le estensioni OAuth possono definire codici se intervengono nell’elaborazione iniziale della richiesta inviata. Poiché non c’è interazione con il titolare della risorsa, codici come consent_required [OIDC] non vengono restituiti.

Se il client deve usare Request Object firmati (policy del server o del client, [RFC9101] sezione 10.5), il server DEVE accettare solo richieste conformi alla sezione 3 e rifiutare le altre con HTTP 400 e invalid_request.

L’endpoint PAR PUÒ inoltre usare:

405 : metodo diverso da POST — HTTP 405 (Method Not Allowed).

413 : payload oltre il limite del server — HTTP 413 (Payload Too Large).

429 : eccesso di richieste del client — HTTP 429 (Too Many Requests).

Esempio:

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"
}