401 vs 403: der richtige Status für eine abgelehnte Anfrage

401 vs 403

401 vs 403: Unauthorized oder Forbidden, was du zurückgibst | We.Inc

401 heißt nicht authentifiziert, 403 heißt authentifiziert, aber nicht erlaubt. Beantworte vier Fragen zu einer Anfrage und erhalte den richtigen Status mit Headern und Code.

Gib 401 Unauthorized zurück, wenn die Anfrage keine gültigen Zugangsdaten hat: kein Token, eine abgelaufene Session, eine ungültige Signatur. Ein Login könnte das beheben, und die Antwort muss einen WWW-Authenticate-Header enthalten. Gib 403 Forbidden zurück, wenn du weißt, wer der Aufrufer ist, und er das trotzdem nicht darf. Ein erneutes Anmelden ändert dann nichts.

Unauthorized und Forbidden im Vergleich

401 Unauthorized
403 Forbidden

Bedeutet eigentlich
Nicht authentifiziert
Nicht erlaubt

Hilft ein Login?
Ja
Nein

Pflicht-Header
WWW-Authenticate
Keiner vorgeschrieben

Typische Ursache
Fehlendes oder abgelaufenes Token oder fehlende Session
Rollen- oder Besitzprüfung fehlgeschlagen

Der Client sollte
Sich anmelden oder das Token erneuern und es erneut versuchen
Aufhören und eine Meldung zum Zugriff anzeigen

Beantworte vier Fragen zu der Anfrage, die dein Server ablehnt. Die Auswahl liefert den Status, den du senden solltest, den passenden Header und eine einzeilige Begründung für einen Code-Kommentar. Sie deckt auch den Fall ab, in dem du lieber nicht zugeben willst, dass die Ressource existiert.

Gib an, ob die Anfrage überhaupt Zugangsdaten mitgebracht hat.
Gib an, ob diese Zugangsdaten gültig waren.
Gib an, ob dieser Aufrufer die Berechtigung für diese Aktion auf dieser Ressource hat.
Entscheide, ob die Existenz der Ressource vor Aufrufern ohne Zugriff verborgen bleiben soll.

Der Name Unauthorized ist ein historischer Unfall. 401 betrifft die Authentifizierung, also wer du bist, 403 die Autorisierung, also was du darfst.
Behandle 401 in einer Single-Page-App als Auslöser, das Token zu erneuern oder den Anmeldebildschirm zu zeigen, und 403 als Meldung, die der Nutzer durch Anmelden nicht beheben kann.
Verwende 404 statt 403 für private Ressourcen, deren Existenz selbst sensibel ist, etwa die Rechnungs-ID eines anderen Kunden.
Protokolliere 403-Antworten mit der Nutzer-ID und der fehlgeschlagenen Berechtigung. So erkennst du am schnellsten eine falsch eingerichtete Rolle.

Häufige Fragen

Was ist der Hauptunterschied zwischen 401 und 403?

401 sagt, dass der Server nicht weiß, wer du bist, oder den Nachweis, den du geschickt hast, nicht akzeptiert hat. 403 sagt, dass er weiß, wer du bist, und die Antwort trotzdem nein lautet.

Muss eine 401-Antwort den WWW-Authenticate-Header enthalten?

Ja. Laut RFC 9110 muss ein Server, der eine 401-Antwort erzeugt, mindestens ein WWW-Authenticate-Headerfeld mit einer Challenge senden, etwa Bearer bei Token-APIs.

Bekommt ein abgelaufenes Token 401 oder 403?

401. Die Zugangsdaten sind nicht mehr gültig, und neue würden das Problem lösen. Eine Bearer-Challenge kann das mit error="invalid_token" mitteilen.

Kann ich 404 statt 403 zurückgeben?

Ja. Die Spezifikation erlaubt einem Server, 404 statt 403 zu senden, um zu verbergen, ob die Ressource existiert. Das ist eine gängige Wahl für IDs, die anderen Nutzern gehören.

Bedeutet ein 403, dass meine IP-Adresse gesperrt ist?

Das kann sein. Server senden 403 bei jeder Ablehnung, die sie für diese Anfrage als endgültig betrachten: IP-Regeln, fehlende Dateirechte, eine Firewall-Regel oder eine fehlgeschlagene Rollenprüfung. Der Antworttext oder das Serverlog sagt meist, was davon zutrifft.

Zwei verschiedene Fragen

Jede geschützte Anfrage beantwortet zwei Fragen der Reihe nach. Wer ruft an? Das ist Authentifizierung, und wer daran scheitert, bekommt 401. Darf dieser Aufrufer das tun? Das ist Autorisierung, und wer daran scheitert, bekommt 403.
Diese Trennung hilft Clients. Ein 401 sagt einem Frontend, dass es den Nutzer zur Anmeldung schicken soll. Ein 403 sagt ihm, dass erneutes Anmelden nicht hilft und stattdessen eine Meldung zum Zugriff auf den Bildschirm gehört.

Was die Spezifikation ergänzt

Hatte eine Anfrage bereits Zugangsdaten und bekommt trotzdem 401, sagt der Server damit, dass diese Zugangsdaten abgelehnt wurden. Bei einem 403 kann der Server den Grund im Body erklären oder gar nichts dazu sagen.

Die Prüfung im Code

Express-Middleware: erst 401, dann 403

verifyToken steht für deine eigene Session- oder JWT-Prüfung. Die Reihenfolge ist wichtig: erst authentifizieren, dann autorisieren.

Frontend: auf beide unterschiedlich reagieren

Ein Codepfad schickt den Nutzer zur Anmeldung, der andere erklärt die Ablehnung.

Welchen Status sollte ich zurückgeben?

Nein

Hatte die Anfrage Zugangsdaten dabei (Session-Cookie, Token, Authorization-Header)?

Waren diese Zugangsdaten gültig und nicht abgelaufen?

Darf dieser Aufrufer diese Aktion auf dieser Ressource ausführen?

Sollen Aufrufer ohne Zugriff nicht erfahren, dass die Ressource existiert?

Sende das

Niemand ist angemeldet. Fordere mit einer Challenge Zugangsdaten an.

Zugangsdaten kamen an, wurden aber abgelehnt. Neue würden das Problem lösen.

Der Aufrufer ist bekannt, hat aber keine Berechtigung. Erneutes Anmelden hilft nicht.

Dem Aufrufer fehlt die Berechtigung, und du willst lieber nicht verraten, dass die Ressource existiert.