HTTP 401 Unauthorized: Bedeutung und Behebung

Was dieser Fehler bedeutet und wie du ihn erkennst

• Ein Browser, API-Client, Monitoring-Tool oder Website-Checker meldet 401 Unauthorized.
• Eine geschützte Seite oder API-Route fordert zur Anmeldung auf, weist eine Session zurück oder gibt einen Authentifizierungsfehler im Response-Body zurück.
• Derselbe Host kann einige öffentliche URLs erfolgreich ausliefern, während eine Route oder Request-Methode 401 zurückgibt.
• Eine Anfrage kann HTTP 401 erhalten, obwohl DNS-Auflösung und TLS-Aushandlung funktionieren.
• Response-Header können Authentifizierungsanforderungen, Weiterleitungen, das Cache-Verhalten, einen Proxy oder ein CDN und manchmal eine Request- oder Correlation-ID nennen.
• Anfragen mit einer Browser-Session können sich anders verhalten als Anfragen eines API-Clients oder Monitoring-Dienstes.

Hauptursachen nach Wahrscheinlichkeit

1. Fehlende oder ungültige Authentifizierung — Die Anfrage enthält keine Zugangsdaten, eine abgelaufene Session, ein ungültiges Token, ein falsches Passwort oder einen falsch formatierten Authorization-Header.
2. Falscher Anfragekontext — Der Client verwendet die falsche URL, HTTP-Methode, den falschen Host, die falsche Audience, den falschen Scope, das falsche Cookie, den falschen API-Key oder die falsche Umgebung. Daher werden Zugangsdaten, die an anderer Stelle gültig sind, hier nicht akzeptiert.
3. Authentifizierungsregeln der Anwendung — Middleware, Route Guards oder die Session-Validierung weisen die Anfrage zurück, bevor der Application Handler ausgeführt wird.
4. Regeln von Webserver, Reverse Proxy, CDN oder WAF — Eine Infrastrukturkomponente erfordert eine Authentifizierung oder leitet unvollständige, veränderte oder fehlende Zugangsdaten weiter.
5. Cache- oder Routing-Verhalten — Eine gecachte Antwort, eine unerwartete Weiterleitung, eine veraltete Route oder eine Host-/Protocol-Abweichung leitet den Client zu einem Endpoint mit anderen Authentifizierungsanforderungen.
6. Änderungen an Upstream-Konfiguration oder Dienst — Ein Deployment, eine Änderung am Identity Provider, eine Secret-Rotation, eine Proxy-Änderung oder eine Abweichung zwischen Umgebungen führt dazu, dass zuvor gültige Anfragen fehlschlagen.

So behebst du den Fehler

Für Besucher

1. Prüfen Sie die genaue Adresse und versuchen Sie es einmal erneut, ohne die Seite wiederholt zu aktualisieren.
2. Wenn die Ressource ein Konto erfordert, melden Sie sich über die normale Oberfläche der Website an und versuchen Sie es erneut. Prüfen Sie, ob die Session abgelaufen ist.
3. Wenn nur ein Link fehlschlägt, melden Sie die konkrete URL, statt anzunehmen, dass die gesamte Website nicht verfügbar ist.
4. Notieren Sie die ungefähre Uhrzeit, die Seite oder den API-Endpoint sowie die angezeigte 401-Meldung. Senden Sie keine Passwörter, Cookies, Access-Tokens oder andere Geheimnisse.
5. Wenden Sie sich an den Betreiber der Website, wenn eine normalerweise öffentliche Seite 401 zurückgibt oder die Anmeldung erfolgreich ist, die geschützte Ressource aber weiterhin nicht erreichbar bleibt.

Für API-Clients und Entwickler

1. Reproduzieren Sie den Fehler mit derselben HTTP-Methode, URL, demselben Host, denselben Query-Parametern, Headern und Body wie beim fehlschlagenden Client. Verwenden Sie nach Möglichkeit ein Nicht-Produktionskonto oder Testzugangsdaten.
2. Prüfen Sie, ob die Zugangsdaten vorhanden, nicht abgelaufen, korrekt formatiert und für diesen Host, diese Route und diese Umgebung vorgesehen sind. Kontrollieren Sie Token-Scope oder Audience, sofern das Authentifizierungssystem diese verwendet.
3. Erfassen Sie Status, Response-Header und Response-Body, ohne Geheimnisse offenzulegen. Achten Sie besonders auf Informationen zur Authentifizierungs-Challenge, Weiterleitungen, Cache-Header und Request-IDs.
4. Vergleichen Sie eine bekanntermaßen funktionierende Anfrage mit der fehlschlagenden Anfrage, jeweils nur mit einer Änderung. Prüfen Sie Cookies, Authorization-Header, Proxy-Weiterleitung, Weiterleitungen und die Request-Methode.
5. Ermitteln Sie die Komponente, die die Antwort erzeugt hat: Anwendung, Webserver, Reverse Proxy, CDN oder WAF. Response-Body, charakteristische Header und spezifische Logs der jeweiligen Ebene können bei der Unterscheidung helfen.
6. Prüfen Sie die passenden Logs anhand von Zeitstempel, Route, Client und Request-ID. Kontrollieren Sie kürzlich erfolgte Deployments, Änderungen am Identity Provider, Secret-Rotation, Routing-Updates und die Proxy-Konfiguration.
7. Nehmen Sie die kleinste autorisierte Korrektur vor — beispielsweise die Korrektur routenspezifischer Zugangsdaten oder einer Weiterleitungsregel — und testen Sie dieselbe Anfrage erneut. Deaktivieren Sie nicht die Authentifizierung, cachen Sie private Antworten nicht öffentlich und vergeben Sie als erste Maßnahme keine umfassenden Berechtigungen.
8. Testen Sie verwandte öffentliche und geschützte Routen, relevante HTTP-Methoden und das vorgesehene Verhalten ohne Authentifizierung, um sicherzustellen, dass die Korrektur kein Zugriffskontrollproblem verursacht hat.

401 von ähnlichen Fehlern unterscheiden

• 401 Unauthorized: Die Authentifizierung fehlt, ist ungültig oder wird vom Endpoint nicht akzeptiert.
• 403 Forbidden: Der Server hat die Anfrage verstanden, autorisiert den Zugriff aber nicht. Eine gültige Authentifizierung kann dennoch vorhanden sein.
• 404 Not Found: Die Route oder Ressource ist an dieser Stelle nicht verfügbar, wobei manche Systeme geschützte Ressourcen absichtlich auf diese Weise verbergen.
• 5xx-Antwort: Die serverseitige Verarbeitung ist fehlgeschlagen, statt die Authentifizierung lediglich zurückzuweisen.

Vorbeugung und Überprüfung der Lösung

• Überwachen Sie Authentifizierungsfehler nach Route, Methode, Client-Typ und Deployment, damit ein isoliertes Routenproblem von einem größeren Vorfall unterschieden werden kann.
• Halten Sie die Konfiguration von Authentifizierung, Routing, Proxy und Caching versionskontrolliert und prüfen Sie Änderungen vor dem Release.
• Testen Sie für wichtige Webrouten und API-Methoden die erwarteten Antworten ohne Authentifizierung, mit Authentifizierung und bei unzureichenden Berechtigungen.
• Verwenden Sie getrennte Zugangsdaten und Konfigurationen für Entwicklung, Tests und Produktion. Rotieren Sie Secrets über einen kontrollierten Prozess.
• Verhindern Sie, dass Access-Tokens, Cookies und Passwörter in Anwendungs-, Proxy-, Monitoring- oder Support-Logs erscheinen.
• Bewahren Sie bereinigte Request-IDs, Zeitstempel und Logs der jeweiligen Ebenen lange genug auf, um Authentifizierungsfehler zu untersuchen.
• Dokumentieren Sie, welche Routen absichtlich öffentlich, geschützt oder nach Methode und Client-Typ eingeschränkt sind.

Häufig gestellte Fragen