Sie öffnen ein Dashboard, das Sie gestern noch benutzt haben, und Chrome zeigt eine schlichte graue Seite: „Diese Seite funktioniert nicht“, ganz unten HTTP ERROR 401. Auf einem Firmenserver lautet derselbe Code „401 - Unauthorized: Access is denied due to invalid credentials.“ In Postman ist es eine rote 401 neben einem API-Aufruf, der vor einer Stunde noch funktioniert hat.
Alle drei sind ein und derselbe HTTP-Statuscode: Der Server wollte wissen, wer Sie sind, und hat keine Antwort bekommen, die er akzeptiert. Im Folgenden: was der Code bedeutet, worin er sich von 400, 403 und 407 unterscheidet, was Besucher und Entwickler tun können, und ein echter Test mit cURL.
Was bedeutet 401 Unauthorized?
Ein 401 bedeutet, dass der Server Ihre Anfrage nicht ausgeführt hat, weil sie ohne gültige Anmeldedaten kam. Der HTTP-Standard RFC 9110 definiert den Code in Abschnitt 15.5.2 als Anfrage, der gültige Authentifizierungsdaten für die Zielressource fehlen. Anmeldedaten sind alles, was beweist, wer Sie sind: ein Passwort, ein Sitzungscookie, ein API-Schlüssel oder ein Token.
Der Server muss außerdem einen Header WWW-Authenticate senden, der dem Client sagt, wie er sich anmelden soll. Enthielt die Anfrage bereits Anmeldedaten, bedeutet der 401, dass sie abgelehnt wurden.
Der Name führt in die Irre. Authentifizierung beantwortet die Frage „Wer sind Sie?“, Autorisierung die Frage „Was dürfen Sie?“. Ein 401 betrifft die erste Frage; eine Absage bei der zweiten ist ein 403 Forbidden.
Wie sieht ein 401-Fehler aus?
Das hängt davon ab, wer ihn anzeigt: Browser, Webserver und API formulieren ihn jeweils anders.
| Was Sie sehen | Angezeigt von | Was es bedeutet |
|---|---|---|
| „Diese Seite funktioniert nicht“, „HTTP ERROR 401“ | Chrome | Die Website hat einen 401 ohne eigene Seite geschickt |
| Ein kleines Fenster, das Benutzername und Passwort verlangt | Ihr Browser | Die Website nutzt die HTTP-Anmeldung (Basic) |
| „401 - Unauthorized: Access is denied due to invalid credentials.“ | IIS, der Webserver von Microsoft | IIS hat die Anmeldung nicht akzeptiert |
401 und eine kurze JSON-Meldung | Eine API, in Postman oder im Code | Schlüssel oder Token fehlt, ist falsch oder abgelaufen |
Die Seite von Chrome (hier in der deutschen Fassung) sagt nichts über die Ursache; in unserem Test zeigte Chromium, die Engine hinter Chrome, sie bei einem 401 mit leerem Antworttext.
Was ist der Header WWW-Authenticate?
WWW-Authenticate ist der Antwort-Header, in dem der Server sein Anmeldeverfahren nennt, das sogenannte Schema. Die Referenz von MDN zeigt die vollständige Syntax. Basic verlangt Benutzername und Passwort, Base64-kodiert gesendet (nicht verschlüsselt, also nur über HTTPS sicher); Browser beantworten es mit ihrem Anmeldefenster. Bearer verlangt ein Token, das Format, das OAuth 2.0 verwendet. Negotiate und NTLM sind die Windows-Anmeldung in Firmennetzen.
WWW-Authenticate: Basic realm="Staging server", charset="UTF-8"
WWW-Authenticate: Bearer realm="example", error="invalid_token"Bei Tokens lesen Sie den Wert error. RFC 6750, der Standard für Bearer-Tokens, definiert invalid_token für ein abgelaufenes, widerrufenes oder fehlerhaftes Token (401), insufficient_scope für ein Token ohne die nötige Berechtigung (403) und invalid_request für eine fehlerhaft aufgebaute Anfrage (400). Eine Anfrage ganz ohne Token bekommt nur die Aufforderung zur Anmeldung, ohne Fehlercode. Viele APIs lassen den Header trotz der Regel weg; dann verrät nur der Antworttext den Grund.
Wie entsteht ein 401, Schritt für Schritt?
Ein 401 ist die erste Hälfte eines kurzen Austauschs:
- Die Anfrage. Ihr Browser oder Skript fragt eine geschützte Seite ohne Anmeldedaten an oder mit solchen, die nicht mehr gelten.
- Die Aufforderung (Challenge). Der Server antwortet mit 401 und nennt das Schema in
WWW-Authenticate. - Die Anmeldedaten. Der Browser öffnet sein Anmeldefenster, die App schickt Sie zu ihrer Anmeldeseite, oder Ihr Code fordert ein Token an.
- Die Wiederholung. Die Anfrage geht erneut hinaus, diesmal mit einem Header
Authorization, etwaAuthorization: Bearer <token>. - Das Urteil. Gültige Anmeldedaten bekommen die Seite (200 OK), ungültige einen weiteren 401, gültige ohne Berechtigung einen 403.
Die meisten Websites mit Anmeldeformular schicken einen abgemeldeten Besucher auf die Anmeldeseite, statt einen 401 zu senden. Ein 401 im Browser kommt deshalb meist aus einem Admin-Bereich, einem Firmen-Intranet oder von einer Web-App, deren Aufrufe an die eigene API abgelehnt werden.
Was ist der Unterschied zwischen 400, 401, 403 und 407?
Die vier Codes unterscheiden sich darin, wer ablehnt und warum: 400 ist eine Anfrage, die der Server nicht lesen kann, 401 eine fehlende oder abgelehnte Anmeldung, 403 ein bekannter Nutzer ohne Berechtigung und 407 Ihr Proxy, der eigene Anmeldedaten verlangt.
| Code | Wer lehnt ab | Was es bedeutet | Was hilft |
|---|---|---|---|
400 | Die Website oder API | Die Anfrage ist fehlerhaft aufgebaut | Die Anfrage korrigieren |
401 | Die Website oder API | Keine gültigen Anmeldedaten | Anmelden oder ein gültiges Token senden |
403 | Die Website oder API | Bekannt, aber nicht berechtigt | Ein anderes Konto oder die Erlaubnis der Website |
407 | Ihr Proxy | Der Proxy will Anmeldedaten | Benutzername und Passwort des Proxys oder die IP-Liste |
Ein 401 lädt Sie ein, es mit Anmeldedaten erneut zu versuchen; ein 403 sagt, dass dieselben Anmeldedaten nicht helfen. Fehlercode 403 Forbidden: Bedeutung und Lösungen behandelt diesen Fall.
Ein 400 kommt noch früher: Der Server konnte die Anfrage nicht lesen und hat daher nie geprüft, wer sie geschickt hat, wie unser Leitfaden zum Fehler 400 Bad Request erklärt.
Ein Proxy, der Anmeldedaten verlangt, antwortet mit 407 Proxy Authentication Required und einem Header Proxy-Authenticate, nie mit 401. Die Lösung sind Benutzername und Passwort des Proxys oder Ihre IP-Adresse auf seiner Whitelist (Freigabeliste), nicht Ihr Login auf der Website. HTTP 407 Proxy Authentication Required beheben zeigt, wo die Proxy-Anmeldedaten in jedem Tool hingehören.
Sieht der Proxy Ihr Token? Nicht bei einer https://-Adresse: Der Client öffnet mit einer CONNECT-Anfrage einen Tunnel durch den Proxy, und der Header Authorization reist innerhalb der verschlüsselten Verbindung zur Website. Der Proxy sieht nur Hostname und Port; so transportiert ein HTTPS-Proxy API-Aufrufe. Über einfaches http:// geht das Token als lesbarer Text durch.
Warum bekomme ich einen 401-Fehler?
Für Besucher bedeutet ein 401 fast immer, dass die Website Ihre Anmeldung nicht mehr erkennt oder sie nie erhalten hat:
- Ihre Sitzung ist abgelaufen, nach längerer Inaktivität, einer Passwortänderung oder einer Abmeldung auf einem anderen Gerät, oder das Cookie der Website (die kleine Datei, in der sie sich an Sie erinnert) ist beschädigt.
- Ihr Passwortmanager hat ein anderes Konto eingetragen, etwa Ihr privates auf einer Website, auf der Sie auch ein Arbeitskonto haben.
- Sie haben das Anmeldefenster des Browsers abgebrochen oder darin ein falsches Passwort eingegeben.
- Der Link war für jemand anderen gedacht. Geteilte Dashboards und Testserver verlangen womöglich ein Konto, das Sie nicht haben.
- Eine Firmenseite erwartet Ihr Arbeitskonto und lehnt einen privaten Computer oder einen Browser außerhalb des Firmennetzes ab.
Fehler 401 beheben: Was Sie als Besucher tun können
Gehen Sie die Punkte der Reihe nach durch; die ersten dauern nur Sekunden.
- Adresse prüfen. Ein Tippfehler oder ein altes Lesezeichen kann in einen geschützten Bereich führen; öffnen Sie die Seite über die Startseite der Website.
- Ab- und wieder anmelden, damit Sie eine neue Sitzung bekommen.
- Das Konto prüfen. Sehen Sie nach, welchen Benutzernamen Ihr Passwortmanager eingetragen hat, und tippen Sie die Anmeldedaten einmal von Hand ein.
- Die Cookies dieser Website löschen. In Chrome: Dreipunkt-Menü > Einstellungen > Datenschutz und Sicherheit > Drittanbieter-Cookies > Alle Websitedaten und -berechtigungen ansehen, nach der Website suchen und Löschen wählen. Damit werden Sie nur bei dieser Website abgemeldet.
- Ein privates Fenster probieren. In Chrome Dreipunkt-Menü > Neues Inkognitofenster (Strg + Umschalt + N). Es startet ohne die Cookies der Website und ohne Erweiterungen, die Sie dort nicht zugelassen haben. Funktioniert die Seite dort, hat ein Cookie oder eine Erweiterung den 401 verursacht.
- Das Anmeldefenster mit den Anmeldedaten beantworten, die Sie bekommen haben. Erscheint es immer wieder, sind sie falsch; fragen Sie die Person, die Ihnen den Zugang gegeben hat.
- Die Website oder Ihre IT kontaktieren und dabei die Adresse, die Uhrzeit und das verwendete Konto nennen.
Für einen 401 gibt es nur eine ehrliche Lösung: Anmeldedaten, die für Sie ausgestellt wurden. Andere Passwörter auszuprobieren oder das Konto eines anderen zu benutzen, ist unbefugter Zugriff, und wiederholte Fehlversuche können das Konto sperren.
Fehler 401 beheben: Was Sie als Entwickler tun können
Im Code bedeutet ein 401, dass der Server nicht akzeptiert hat, was im Header Authorization ankam; prüfen Sie also zuerst die Anfrage und erst dann das Konto. Lesen Sie als Erstes den Wert von WWW-Authenticate und den Antworttext.
- Der Header fehlt. Steht in der Ausgabe von
curl -vkeine Zeile> Authorization:, wurde nichts gesendet. Die üblichen Verdächtigen: eine leere Umgebungsvariable oder eine Weiterleitung. cURL verwirft den HeaderAuthorization, wenn eine Weiterleitung zu einem anderen Host, Port oder Protokoll (http oder https) führt, es sei denn, Sie ergänzen--location-trusted; in unserem Test machte eine Weiterleitung vonlocalhostauf127.0.0.1aus einem 200 einen 401. - Das Schema ist falsch. Ein Token gehört in
Authorization: Bearer <token>, Benutzername und Passwort gehören zuBasic. Ein als Basic gesendetes Token,Token, wo die APIBearererwartet, oder ein API-Schlüssel in einem Header, den die API nicht liest, enden alle mit 401. Nach dem Schema steht genau ein Leerzeichen, Anführungszeichen gibt es keine. - Das Token ist abgelaufen oder widerrufen.
error="invalid_token"in der Challenge sagt genau das. Holen Sie ein neues Token, mit einem Refresh-Token, falls Sie eines haben, und wiederholen Sie die Anfrage einmal. - Die Uhren gehen unterschiedlich. Ein JWT (JSON Web Token) trägt seinen eigenen Ablaufzeitpunkt (
exp) und Startzeitpunkt (nbf), die gegen die Uhr des Servers geprüft werden. Eine Uhr, die ein paar Minuten falsch geht, lässt ein frisches Token abgelaufen oder noch nicht gültig aussehen; der JWT-Standard sieht höchstens wenige Minuten Toleranz vor, synchronisieren Sie also beide Rechner per NTP. - Das Token gehört woandershin: ein Staging-Token, das an die Produktion geht, oder eines, das für eine andere API ausgestellt wurde. Ein JWT nennt seinen vorgesehenen Empfänger im Claim
aud(Audience), und ein Server, der sich dort nicht findet, muss es ablehnen. - Der Preflight des Browsers wird abgelehnt. Vor einer Cross-Site-Anfrage mit Header
Authorizationsendet der Browser eineOPTIONS-Anfrage, den CORS-Preflight, der nie Anmeldedaten enthält. Verlangt der Server auch dort ein Token, antwortet er mit 401, und die eigentliche Anfrage geht nie hinaus. Beantworten SieOPTIONSohne Authentifizierung. - Die Einrichtung des Servers selbst. Bei IIS nennt die Zahl nach dem Punkt den Grund: 401.1 eine fehlgeschlagene Anmeldung, 401.2 die Authentifizierungseinstellungen des Servers, 401.3 Dateiberechtigungen; Microsofts Liste der IIS-Statuscodes enthält den Rest. Im IIS-Manager zeigt das Feature Authentication (Authentifizierung) der Website, welche Verfahren aktiviert sind.
Stößt Ihr Crawler auf einen 401, liegt die Seite hinter einem Login: Sammeln Sie nur öffentliche Seiten, oder nutzen Sie die offizielle API der Website mit einem Schlüssel, der für Sie ausgestellt wurde. Wiederholen Sie einen 401 nie in einer Schleife; ohne neue Anmeldedaten kann der Versuch nicht gelingen.
Wie testen Sie einen 401 mit cURL?
curl -i gibt die Statuszeile und die Antwort-Header über dem Antworttext aus; das genügt, um einen 401 und seine Challenge zu sehen. Wir haben auf unserem eigenen Computer eine kleine Test-API in Node.js geschrieben, deren Endpunkt /api/profile mit 401 antwortet, solange die Anfrage nicht demo-token-123 enthält, ein erfundenes Token. Aufgerufen haben wir sie mit dem in Windows 11 eingebauten cURL 8.22:
curl -i http://localhost:8401/api/profileHTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"
Content-Type: application/json
Content-Length: 21
Date: Thu, 12 Nov 2026 01:20:35 GMT
Connection: keep-alive
Keep-Alive: timeout=5
{"error":"no token"}Dann mit dem Token:
curl -i -H "Authorization: Bearer demo-token-123" http://localhost:8401/api/profileHTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 16
Date: Thu, 12 Nov 2026 01:20:35 GMT
Connection: keep-alive
Keep-Alive: timeout=5
{"user":"demo"}Mit einem veralteten Token antwortete der Server mit 401 und error="invalid_token". In Windows PowerShell 5.1 ist curl eine Abkürzung für Invoke-WebRequest; tippen Sie dort deshalb curl.exe.
Was ist der Unterschied zwischen einem API-Schlüssel und einem OAuth-Token?
Ein API-Schlüssel ist ein langlebiges Geheimnis, das Ihre Anwendung oder Ihr Konto ausweist; ein OAuth-Zugriffstoken ist ein kurzlebiger Ausweis, der nach einer Anmeldung ausgestellt wird.
| Frage | API-Schlüssel | OAuth-Zugriffstoken |
|---|---|---|
| Ausgestellt von | Dem Dashboard des Dienstes | Einem Anmeldeserver, nach einer Anmeldung |
| Gültigkeit | Bis zum Löschen oder Rotieren | Minuten oder Stunden; ein Refresh-Token erneuert es |
| Gesendet als | Header oder Parameter, den die API vorgibt | Authorization: Bearer <token> |
| Typische 401-Ursache | Vertippt, gelöscht oder an der falschen Stelle | Abgelaufen oder für eine andere API ausgestellt |
Ein Token ohne den passenden Scope, also die Liste dessen, was es tun darf, bekommt einen 403 statt eines 401. Bewahren Sie Schlüssel und Tokens in Umgebungsvariablen oder einem Secrets-Manager auf, nie in einem Code-Repository.
Wo Ihnen ein 401 begegnen kann
- Admin-Bereiche und Testserver, die mit dem Anmeldefenster des Browsers geschützt sind.
- Seiten im Firmen-Intranet, die die Windows-Anmeldung nutzen.
- APIs und Webhooks nach einer Schlüsselrotation oder dem Ablauf eines Tokens.
- Postman- oder Bruno-Collections mit einem veralteten Token.
- Crawler und Monitoring-Skripte, die Seiten hinter einem Login erreichen.
Häufige Fehler
- Einen 401 wie einen 403 behandeln. Mehr Berechtigungen helfen nicht, wenn das Token fehlt.
- In einer Schleife wiederholen, was ein Konto sperren oder ein Rate Limit auslösen kann.
- Echte Tokens einfügen, in Tickets, Screenshots oder geteilte
curl -v-Ausgaben. - Auf dem Server ein Token für
OPTIONSverlangen. - Einen 401 ohne
WWW-Authenticatesenden, obwohl der Standard den Header vorschreibt.
Entscheidungshilfe
| Ihre Lage | Was tun |
|---|---|
| Chrome zeigt „HTTP ERROR 401“ | Neu anmelden, dann die Cookies dieser Website löschen |
| Der Browser fragt immer wieder nach einem Passwort | Die Anmeldedaten mit der Person klären, die Ihnen den Zugang gab |
| „Access is denied due to invalid credentials“ | Ihr Arbeitskonto verwenden; Admins lesen den 401.x-Code |
Keine Zeile > Authorization: in curl -v | Die Variable oder Weiterleitung korrigieren, die den Header verwirft |
error="invalid_token" | Ein neues Token holen und einmal wiederholen |
| 407 statt 401 | Die Proxy-Anmeldedaten korrigieren, nicht den Login auf der Website |
Häufige Fragen
Warum bekomme ich 401 Unauthorized in Postman?
Meist sendet die Anfrage nicht das Token, das Sie vermuten. Im Tab Authorization der Anfrage zeigt die Liste Auth type, ob sie ihre eigene Einstellung nutzt oder eine aus ihrer Collection oder ihrem Ordner (unter Inherited). Kommt das Token aus einer Variablen, wählen Sie die richtige Umgebung (Environment) und prüfen Sie, ob das Token noch gültig ist.
Was bedeutet „Access is denied due to invalid credentials“?
Das ist die Standard-401-Seite von IIS, dem Webserver von Microsoft: Er hat die Anmeldedaten, die Ihr Browser gesendet hat, nicht akzeptiert oder konnte Sie mit dem eingestellten Verfahren nicht anmelden. Besucher verwenden das richtige Arbeitskonto oder fragen die IT; Administratoren lesen die 401.x-Nummer.
Bin ich an einem 401-Fehler schuld oder die Website?
Meist ist es ein Anmeldeproblem, das Sie selbst beheben können: eine abgelaufene Sitzung, ein veraltetes Cookie, das falsche gespeicherte Konto. Scheitern die richtigen Anmeldedaten auch mit frischen Cookies, ist die Anmeldung der Website defekt.
Warum hat eine 401-Antwort keinen Antworttext?
Der Standard verlangt keinen; er verlangt den Header WWW-Authenticate, lesen Sie also die Header. Ein Browser, der einen leeren 401 bekommt, zeigt seine eigene Seite; in unserem Test zeigte Chromium „Diese Seite funktioniert nicht“.
Kann ein VPN oder Proxy einen 401-Fehler verursachen?
Direkt selten: Ein Proxy, der Anmeldedaten verlangt, antwortet mit 407. Beide ändern aber Ihre IP-Adresse, und manche APIs akzeptieren einen Schlüssel nur von freigegebenen Adressen und lehnen andere mit 401 oder 403 ab. Für eine solche API behält ein ISP-Proxy dieselbe Ausgangs-IP.
Sollte mein Code einen 401 automatisch wiederholen?
Einmal, und nur nachdem er neue Anmeldedaten geholt hat, etwa ein erneuertes Token. Kommt dieselbe Challenge zurück, hören Sie auf und melden den Fehler.
Fazit
Ein 401 Unauthorized bedeutet, dass der Server keine Anmeldedaten bekommen hat, die er akzeptiert, und WWW-Authenticate sagt, welche Art er will. Besucher prüfen die Adresse, melden sich neu an und löschen die Cookies der Website. Entwickler prüfen, ob der Header Authorization mit dem richtigen Schema und einem aktuellen Token gesendet wird. Für API-Arbeit, die eine feste Ausgangs-IP oder einen HTTPS-Tunnel braucht, vergleichen Sie die Optionen auf unserer Proxy-Seite.




