401 Unauthorized: Bedeutung und Lösung

2026-09-19

Ein 401 Unauthorized bedeutet, der Anfrage fehlen gültige Zugangsdaten, oder die gesendeten Zugangsdaten wurden abgelehnt. Der Server sagt nicht, dass Sie von der Ressource ausgeschlossen sind, nur dass er noch nicht weiß, wer Sie sind, und er erwartet, dass Sie sich authentifizieren, bevor er die eigentliche Frage beantwortet, was Sie dürfen.

Was 401 Unauthorized bedeutet

RFC 9110 definiert 401 als eine Anfrage, die Authentifizierung verlangt, entweder weil keine mitgeliefert wurde oder weil die mitgelieferte nicht bestanden hat. Eine 401-Antwort muss einen WWW-Authenticate-Header tragen, der das vom Server erwartete Schema benennt, etwa Basic, Bearer, oder Digest. Dieser Header ist der Hinweis, den die meisten übersehen: Er sagt Ihnen genau, welche Art Zugangsdaten der Server will, was meist schneller ist als zu raten.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api", error="invalid_token"

Wie sich der Fehler zeigt

Im Browser löst ein durch HTTP-Basic-Authentifizierung geschützter 401 die native Nutzername-Passwort-Abfrage aus, keine von der Website gerenderte Seite. Ein 401 von einer JSON-API dagegen taucht meist nur in einem Netzwerk-Tab oder einer von der Anwendung dafür gebauten Fehlermeldung auf, da es für einen Bearer-Token-Fehlschlag keine Standard-Browser-Oberfläche gibt. Von der Kommandozeile aus sind sowohl die Zugangsdaten als auch der Header in einer Anfrage sichtbar:

curl -i -H "Authorization: Bearer eyJhbGciOi..." https://api.example.com/v1/account
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_token", error_description="token is expired"

Server- und Anwendungslogs protokollieren üblicherweise auch den Grund, zum Beispiel "token expired", "signature invalid", oder "no Authorization header", was die Ursache schneller eingrenzt als der generische Statuscode allein.

Was einen 401 Unauthorized verursacht

Ungefähr in der Reihenfolge, wie häufig sich das jeweils als Ursache herausstellt:

Es wurden überhaupt keine Zugangsdaten gesendet. Eine abgemeldete Sitzung, ein fehlender API-Schlüssel, oder ein Client, der den Authorization-Header von Anfang an nie angehängt hat.
Ein abgelaufenes Token. Session-Cookies, OAuth-Access-Tokens, und JWTs tragen alle eine Lebensdauer, und ein Client, der ein veraltetes nutzt, bekommt 401, obwohl es Minuten zuvor noch funktionierte.
Uhrenabweichung zwischen Client und Server. Die exp- und nbf-Ansprüche eines JWT werden gegen die Uhr des Servers ausgewertet. Ein Server oder Client mit falscher Zeit kann ein Token ablehnen, das nach der eigenen Rechnung des Tokens noch gültig ist, oder eines akzeptieren, das bereits abgelaufen ist.
Das falsche Authentifizierungsschema. Authorization: Basic ... an einen Endpunkt zu senden, der Bearer erwartet, oder umgekehrt, scheitert, obwohl ein Header vorhanden ist.
Ein API-Schlüssel am falschen Ort. Manche APIs erwarten den Schlüssel in einem eigenen Header wie X-API-Key, andere in Authorization, und wieder andere als Query-Parameter. Einen gültigen Schlüssel am falschen Ort zu platzieren sieht identisch aus wie gar keinen Schlüssel zu senden.
Ein Reverse-Proxy oder Gateway entfernt den Authorization-Header. Manche Proxy- und CDN-Konfigurationen verwerfen Header, die sie nicht ausdrücklich weiterleiten, und ein völlig gültiges Zugangsdatum erreicht den Ursprung nie.
Widerrufene Zugangsdaten. Ein Nutzer hat sein Passwort geändert, ein Admin hat einen API-Schlüssel rotiert, oder ein Token wurde beim Abmelden ausdrücklich für ungültig erklärt.

401 gegenüber 403

Die beiden werden oft verwechselt, weil beide die Anfrage ablehnen, aber die Spezifikation zieht eine klare Grenze. Ein 401 bedeutet, der Server braucht Ihre Authentifizierung, und ein gültiges Zugangsdatum könnte das Ergebnis ändern; er muss WWW-Authenticate tragen. Ein 403 bedeutet, der Server hat genau verstanden, wer Sie sind, und lehnt trotzdem ab, aus einem Grund, den Authentifizierung nicht beheben kann, etwa eine Rollen- oder Tarifbeschränkung. Würde eine erneute Anmeldung plausibel helfen, sollte es 401 sein. Ist der Nutzer bereits angemeldet und einfach nicht berechtigt, sollte es 403 sein, obwohl in der Praxis viele APIs 401 locker für beide Fälle nutzen.

So finden Sie heraus, wer schuld ist

Rufen Sie die API auf, reproduzieren Sie die Anfrage mit einem frischen Zugangsdatum aus einer sauberen Umgebung; gelingt ein neu ausgestelltes Token, ist das alte einfach abgelaufen oder widerrufen worden. Scheitert auch ein brandneues Token, prüfen Sie Schema und Header-Namen gegen die Dokumentation der API, bevor Sie annehmen, der Server sei kaputt. Betreiben Sie den Dienst und Nutzer melden 401er, die Sie mit Ihrem eigenen Konto nicht reproduzieren können, ist der schnellste Weg, "der Server ist in Ordnung, einzelne Tokens sind veraltet" von "die Authentifizierung selbst ist für alle kaputt" zu trennen, eine HTTP-Prüfung mit einem nachweislich gültigen Zugangsdatum von mehreren Standorten gleichzeitig auszuführen und die Ergebnisse zu vergleichen.

So beheben Sie einen 401 Unauthorized

Wenn Sie Besucher sind

Melden Sie sich erneut an. Die meisten 401er einer Webanwendung sind einfach eine abgelaufene Sitzung, und das Anmelden erneuert sie.
Prüfen Sie die Systemuhr auf Ihrem Gerät, falls dieselbe Anmeldung immer direkt nach der Authentifizierung scheitert. Eine um mehrere Minuten falsche Uhr kann zeitbasierte Tokens bei manchen Clients ungültig machen.
Erzeugen Sie einen API-Schlüssel oder ein Token neu in den Kontoeinstellungen, falls Sie vermuten, dass er rotiert oder widerrufen wurde, statt anzunehmen, Ihr Integrationscode habe einen Fehler.
Bestätigen Sie, dass der Authorization-Header tatsächlich gesendet wird, mit dem Netzwerk-Tab Ihres Browsers oder einem einfachen curl-Aufruf, da manche HTTP-Client-Bibliotheken benutzerdefinierte Header bei einer Weiterleitung still verwerfen.

Wenn Sie die Website betreiben

Lesen Sie den WWW-Authenticate-Header und Ihre eigenen Logs auf den konkreten Ablehnungsgrund, bevor Sie irgendetwas ändern; "expired", "invalid signature", und "missing header" deuten jeweils auf eine andere Lösung hin.
Prüfen Sie die Uhrensynchronisation auf den Servern, die Tokens ausstellen und validieren. NTP-Abweichung auf einer der Seiten ist eine klassische, unregelmäßige Ursache für JWT-Ablehnungen, die sonst zufällig wirken.
Verifizieren Sie, dass der Proxy oder Load Balancer den Authorization-Header weiterleitet. Eine aus einem unabhängigen Grund hinzugefügte Regel kann ihn für jede Anfrage hinter diesem Sprung still entfernen.
Dokumentieren Sie das erwartete Schema und den Header-Namen klar in Ihrer API-Dokumentation, und geben Sie eine konkrete error_description im WWW-Authenticate-Header zurück, damit Integratoren nicht raten müssen.
Unterscheiden Sie 401 von 403 in Ihren eigenen Antworten, wo es für Aufrufer wichtig ist, damit Client-Code "erneuern Sie Ihr Token" von "das werden Sie nie dürfen" unterscheiden kann.

So verhindern Sie einen stillen 401-Ausfall

Ein 401, verursacht durch ein abgelaufenes Signaturzertifikat, eine aus dem Takt geratene Uhr, oder eine Proxy-Änderung, die begonnen hat, den Authorization-Header zu entfernen, sieht nicht wie ein Absturz aus. Der Dienst antwortet sofort und korrekt nach seinen eigenen Regeln, er kann also für jeden Aufrufer kaputt bleiben, bis es jemand bemerkt. Eine HTTP-Prüfung mit einer Zusicherung auf den erwarteten Statuscode, ausgeführt mit einem lebenden Zugangsdatum gegen einen authentifizierten Endpunkt, erkennt das in dem Moment, in dem es beginnt. Für APIs im Besonderen erkennt API-Monitoring, das sowohl Antwort-Bodys als auch Statuscodes prüft, kombiniert damit auch ein Token, das authentifiziert, aber fehlerhafte Daten zurückgibt.

Häufig gestellte Fragen

Warum bekomme ich direkt nach erfolgreicher Anmeldung einen 401?

Meist eine Uhrenfehlpassung zwischen Ihrem Gerät und dem Server, oder ein Client, der das alte, jetzt ungültige Token zwischengespeichert hat, statt das frisch ausgestellte zu nutzen. Bestätigen Sie, dass Ihre Systemzeit korrekt ist und das neue Token tatsächlich gesendet wird.

Bedeutet 401, dass mein Konto gehackt wurde?

Nicht für sich allein. Es bedeutet fast immer eine abgelaufene Sitzung, einen widerrufenen Schlüssel, oder einen falsch gesendeten Header. Behandeln Sie es nur dann als Sicherheitsbedenken, wenn Sie nicht erwartet haben, dass das Zugangsdatum aufhört zu funktionieren, und nicht erklären können, warum es das tat.

Was ist der Unterschied zwischen 401 und einem Authentifizierungsfehler auf der TLS-Ebene?

Ein Fehlschlag beim TLS-Client-Zertifikat verhindert, dass die Verbindung überhaupt zustande kommt, es wird also nie ein HTTP-Statuscode zurückgegeben. Ein 401 bedeutet, die Verbindung gelang, und der Server empfing eine vollständige HTTP-Anfrage, lehnte sie dann aber auf Anwendungsebene ab, weil gültige Zugangsdaten fehlten.

Sollte ein Login-Formular selbst jemals 401 zurückgeben?

Nein. Ein Login-Endpunkt, der einen Nutzernamen und ein Passwort auswertet, authentifiziert keine bestehende Anfrage; ein falsches Passwort dort ist konventionell ein 400 oder ein 200 mit einem Fehler-Payload, da der gesamte Zweck des Endpunkts ist, nicht authentifizierte Versuche anzunehmen und zu beurteilen.

Kann ein gültiger API-Schlüssel trotzdem 401 erzeugen?

Ja, wenn er im falschen Header oder falschen Schema gesendet wird, wenn er rotiert wurde, nachdem Ihre Integration den alten zwischengespeichert hat, oder wenn die Anfrage den Server über einen Proxy erreichte, der den Header vor der Weiterleitung entfernt hat.