2.3. Error Response (Fehlerantwort)

2.3. Error Response (Fehlerantwort)

Der Autorisierungsserver sendet Fehlerantworten im gleichen Format wie am Token-Endpunkt (Abschnitt 5.2 von [RFC6749]) und verwendet passende Fehlercodes aus dort oder aus Abschnitt 4.1.2.1 von [RFC6749]. Wenn Abschnitt 4.1.2.1 von [RFC6749] keine automatische Fehlerumleitung vorsieht und keinen Code definiert (z. B. fehlende, ungültige oder nicht übereinstimmende Redirect-URI), KANN invalid_request als Standard dienen. OAuth-Erweiterungen können Codes liefern, wenn die Erweiterung in der ersten Verarbeitung der gepushten Anfrage greift. Da dabei keine Interaktion mit dem Ressourceninhaber stattfindet, werden nutzerbezogene Codes wie consent_required [OIDC] nicht zurückgegeben.

Wenn der Client signierte Request Objects verwenden MUSS (Server- oder Clientrichtlinie, [RFC9101], Abschnitt 10.5), MUSS der Autorisierungsserver nur Anfragen gemäß Abschnitt 3 akzeptieren und alle anderen mit HTTP 400 und invalid_request ablehnen.

Zusätzlich KANN der PAR-Endpunkt folgende HTTP-Status verwenden:

405 : Wenn die Methode nicht POST war — HTTP 405 (Method Not Allowed).

413 : Wenn die Nutzlast die Serverobergrenze überschreitet — HTTP 413 (Payload Too Large).

429 : Wenn die Anfragerate eines Clients überschritten wird — HTTP 429 (Too Many Requests).

Fehlerbeispiel:

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