HTTP-Statuscode 401 oder 403? Wie sich Authentifizierungs- und Autorisierungsfehler unterscheiden

Jedes Mal, wenn du eine Webseite lädst, eine Zahlung vornimmst oder dich in eine App einloggst, findet zwischen deinem Gerät und einem Server ein unsichtbares Gespräch statt. Es ist ein bisschen wie das Senden einer Nachricht und das Warten auf eine Antwort—manchmal ist es ein Daumen hoch, manchmal ein höfliches „Versuch es noch einmal“ und gelegentlich ein klares „Nein“. Diese Antworten, bekannt als HTTP-Statuscodes, sind die unbekannten Helden des Internets, die stille Kommunikation lenken und sicherstellen, dass alles reibungslos abläuft—oder dich zumindest wissen lassen, wenn es nicht so ist.

Was sind HTTP-Statuscodes#

HTTP-Statuscodes sind wie Signale in einem Gespräch zwischen einem Client (wie deinem Browser oder einer App) und einem Server. Sie bieten schnelle und klare Updates darüber, was passiert ist, als du eine Anfrage gestellt hast—ob alles reibungslos verlief, etwas schiefging oder zusätzliche Maßnahmen erforderlich sind. Lass uns das wie einen Besuch in einer gut geführten Bäckerei betrachten:

200: Alles ist perfekt#

Du fragst nach einem Croissant und der Bäcker lächelt, reicht es dir und sagt: „Bitte schön!“ Das ist ein HTTP 200 OK—die Anfrage war erfolgreich und alles funktionierte wie erwartet.

Der 200 OK HTTP-Statuscode ist einer der am häufigsten verwendeten Codes und zeigt an, dass die Anfrage des Clients erfolgreich empfangen, verstanden und vom Server verarbeitet wurde.

301: Wir sind umgezogen#

Du kommst zu deiner Lieblingsbäckerei, aber da hängt ein Schild: „Wir sind nach 123 New Street umgezogen.“ Das ist ein 301 Moved Permanently. Der Server teilt deinem Browser automatisch mit, zur neuen Adresse zu gehen.

Der 301 Moved Permanently HTTP-Statuscode zeigt an, dass die angeforderte Ressource dauerhaft auf eine neue URL verschoben wurde. Dieser Statuscode informiert den Client (z.B. Browser oder API-Client), seine Aufzeichnungen zu aktualisieren und für zukünftige Anfragen die neue URL zu verwenden.

404: Entschuldigung, es ist nicht hier#

Du fragst nach einem Schokoladenscone und der Bäcker sagt: „Die machen wir hier nicht.“ Das ist ein 404 Not Found—die Ressource, die du suchst, existiert auf dem Server nicht.

Der 404 Not Found HTTP-Statuscode zeigt an, dass der Server die angeforderte Ressource nicht finden konnte. Diese Antwort bedeutet, dass die Anfrage des Clients gültig war, aber der Server die angeforderte Ressource nicht lokalisieren konnte.

401: Wer bist du?#

Du versuchst, die VIP-Lounge zu betreten, aber der Türsteher stoppt dich und sagt: „Du musst deine Mitgliedskarte zeigen.“ Das ist ein 401 Unauthorized—Authentifizierung ist erforderlich, bevor du auf die Ressource zugreifen kannst.

Der 401 Unauthorized HTTP-Statuscode zeigt an, dass die Anfrage des Clients nicht angewendet wurde, weil gültige Authentifizierungsdaten fehlen. Der Server erfordert, dass der Client sich authentifiziert, um auf die angeforderte Ressource zuzugreifen.

403: Nicht für dich#

Du zeigst deine Mitgliedskarte, aber der Türsteher sagt: „Nur für Platinmitglieder.“ Das ist ein 403 Forbidden—du bist authentifiziert, aber hast nicht die erforderlichen Berechtigungen, um auf die Ressource zuzugreifen.

Der 403 Forbidden HTTP-Statuscode zeigt an, dass der Server die Anfrage des Clients versteht, sie aber ablehnt, weil der Client nicht die erforderlichen Berechtigungen hat. Dies unterscheidet sich von einem 401 Unauthorized-Status, da der Client authentifiziert ist (oder die Anfrage keine Authentifizierung erfordert), der Zugriff auf die Ressource jedoch ausdrücklich verweigert wird.

500: Der Ofen brennt#

Du bestellst etwas, aber plötzlich strömt Rauch aus der Küche. Der Bäcker sagt: „Wir können deine Bestellung nicht ausführen; intern ist etwas schiefgegangen.“ Das ist ein 500 Internal Server Error—der Server traf auf ein unerwartetes Problem.

Der 500 Internal Server Error HTTP-Statuscode zeigt an, dass der Server auf eine unerwartete Bedingung gestoßen ist, die ihn daran hinderte, die Anfrage zu erfüllen. Es ist eine generische Fehlerantwort und liefert keine spezifischen Details, was schiefgegangen ist.

503: Vorübergehend nicht verfügbar#

Du besuchst die Bäckerei, aber da ist ein „Wegen Wartungsarbeiten geschlossen“-Schild. Die Bäckerei wird später wieder öffnen. Das ist ein 503 Service Unavailable—der Server kann deine Anfrage vorübergehend nicht bearbeiten, oft wegen Überlastung oder Wartungsarbeiten.

Der 503 Service Unavailable HTTP-Statuscode zeigt an, dass der Server vorübergehend nicht in der Lage ist, die Anfrage zu bearbeiten. Dies kann aufgrund von Serverüberlastung, Wartungsarbeiten oder anderen vorübergehenden Bedingungen sein. Im Gegensatz zu einem 500 Internal Server Error impliziert ein 503, dass das Problem voraussichtlich bald behoben wird.

HTTP-Statuscodes sind entscheidend, um eine effiziente Kommunikation zwischen Clients und Servern aufrechtzuerhalten. Sie informieren Clients schnell, ob ihre Anfragen erfolgreich, fehlgeschlagen sind oder weitere Aktionen erfordern. Für Entwickler und IT-Fachleute hilft das Verständnis dieser Codes beim Debuggen von Problemen, dem Design besserer Fehlerbehandlungen und der Verbesserung des gesamten Benutzererlebnisses.

Denk an sie als professionelle, standardisierte Signale im fortlaufenden Gespräch des Internets.

In diesem Artikel möchte ich mich auf die Fehler 401 und 403 konzentrieren, da sie eng mit Authentifizierung (AuthN) und Autorisierung (AuthZ) zusammenhängen.

Wann sollte man 401 Unauthorized verwenden?#

Der 401 Unauthorized HTTP-Statuscode wird verwendet, wenn die Clientanforderung eine Authentifizierung erfordert, diese jedoch entweder fehlt, ungültig ist oder fehlgeschlagen ist. Es teilt dem Client mit, dass er sich authentifizieren muss, um auf die angeforderte Ressource zuzugreifen. Die Beziehung zwischen Authentifizierung und dem 401 Unauthorized-Statuscode liegt in der Rolle der Authentifizierung bei der Bestimmung, ob eine Anfrage fortgesetzt werden kann.

401 Unauthorized muss ein WWW-Authenticate-Header enthalten, der Details zur Authentifizierung bereitstellt.

Was sind also häufige Szenarien für die Verwendung von 401 Unauthorized?

1. Fehlende Authentifizierung

   Die Anfrage enthält nicht die erforderlichen Authentifizierungsdaten. Zum Beispiel: Eine Anfrage an einen geschützten API-Endpunkt erfolgt ohne Authorization-Header.

2. Ungültige Authentifizierungsdaten

   Der Client gibt Anmeldeinformationen an, diese sind jedoch falsch oder entsprechen nicht den Erwartungen des Servers. Zum Beispiel sendet ein Benutzer einen ungültigen API-Schlüssel oder ein fehlerhaftes Token.

3. Abgelaufenes Authentifizierungstoken

   Das Authentifizierungstoken ist gültig, aber abgelaufen, was erfordert, dass der Client sich erneut authentifiziert. Zum Beispiel ein JWT-Token mit einem vergangenen Ablaufdatum (exp-Claim).

4. Fehlender oder fehlerhaft formatierter Authorization-Header

   Der Authorization-Header ist erforderlich, wird jedoch entweder nicht bereitgestellt oder ist falsch formatiert.

5. Nicht unterstütztes Authentifizierungsschema

   Der Server unterstützt die vom Client bereitgestellte Authentifizierungsmethode nicht. Zum Beispiel: Der Client sendet einen Basic-Authentifizierungsheader, aber der Server unterstützt nur Bearer-Tokens.

6. Ungültige Sitzung oder Token-Widerruf

   Die Sitzung des Benutzers wurde ungültig gemacht oder sein Token widerrufen. Zum Beispiel: Ein Benutzer meldet sich ab, aber das gleiche Token wird verwendet, um auf eine geschützte Ressource zuzugreifen.

Beispielantwort

Wann sollte man 403 Forbidden verwenden?#

Der 403 Forbidden HTTP-Statuscode bedeutet, dass der Server die Anfrage und die Identität des Clients (falls authentifiziert) versteht, den Zugriff jedoch aufgrund unzureichender Berechtigungen verweigert. Es signalisiert klar, „Du darfst das nicht tun“, und sorgt für klare Zugriffsgrenzen und verstärkt Sicherheitsrichtlinien.

Der Unterschied zwischen 401 Unauthorized und 403 Forbidden liegt in ihren Rollen im Kontext der Authentifizierung und Autorisierung.

Autorisierung ist ein separater Mechanismus von Authentifizierung. Während die Authentifizierung herausfindet, wer du bist, bestimmt die Autorisierung, ob du auf bestimmte Ressourcen zugreifen kannst und welche Aktionen du darauf ausführen darfst.

Um den detaillierten Unterschied zwischen AuthN und AuthZ zu prüfen. Schau dir die folgenden Artikel an.

Was ist AuthZ

Was ist AuthN

Was sind also die häufigen Szenarien für die Verwendung von 403 Forbidden?

1. Authentifiziert, aber ohne Berechtigung

   Der Client ist eingeloggt oder authentifiziert, hat jedoch nicht die erforderlichen Berechtigungen oder Rollen. Zum Beispiel versucht ein Benutzer mit einer „Viewer“-Rolle, eine Datei zu löschen, die „Editor“-Privilegien erfordert.

2. Eingeschränkter Ressourcenzugriff

   Der Zugriff auf die Ressource ist absichtlich auf bestimmte Benutzer oder Gruppen beschränkt. Zum Beispiel: Ein privates Dokument, das mit bestimmten Benutzern geteilt wird, wird von jemandem aufgerufen, der nicht auf der Zugriffsberechtigungsliste steht.

3. IP- oder geografische Blockierung

   Die IP-Adresse oder der geografische Standort des Clients wird vom Server blockiert. Zum Beispiel: Ein Benutzer aus einer eingeschränkten Region versucht, auf einen Dienst zuzugreifen, der nur in bestimmten Ländern betrieben wird.

4. Durch Richtlinien blockierte Aktionen

   Der Client versucht, eine Aktion durchzuführen, die durch serverseitige Richtlinien oder Regeln verboten ist. Zum Beispiel: Ein Benutzer versucht eine Ressource zu ändern, die als „Nur-Lese“ markiert ist.

5. Blockierte statische Ressourcen

   Der Server verweigert den Zugriff zu bestimmten statischen Dateien oder Verzeichnissen aus Sicherheitsgründen.

   Beispiel: Ein Benutzer versucht, auf eine .htaccess-Datei oder die Konfigurationsdatei eines Servers zuzugreifen.

6. Konto gesperrt oder deaktiviert

   Das Konto des Clients ist gesperrt oder aufgrund von Verstößen oder Inaktivität blockiert. Zum Beispiel: Ein Benutzer mit einem gesperrten Konto versucht, sich anzumelden oder auf Ressourcen zuzugreifen.

7. Aktion erfordert erhöhte Berechtigungen

   Die angeforderte Aktion erfordert besondere Privilegien (z.B. Admin oder Superuser). Zum Beispiel: Ein Standardbenutzer versucht, auf Admin-only-Endpunkte zuzugreifen.

Beispielantwort:

Wie kann ich einen 401-Unauthorized-Fehler beheben#

Ein 401-Fehler zeigt normalerweise an, dass eine Authentifizierung erforderlich ist und fehlgeschlagen ist.

Anmeldedaten überprüfen#

Stelle sicher, dass der Authorization-Header vorhanden und korrekt formatiert ist, und überprüfe, ob die Anmeldedaten (API-Schlüssel, Token oder Passwort) korrekt und nicht abgelaufen sind. Das Eingeben eines falschen Benutzernamens oder Passworts ist eine der häufigsten Ursachen für einen 401-Fehler.

Authentifizierungsmethode bestätigen#

Der Server erwartet möglicherweise eine andere Authentifizierungsmethode als die bereitgestellte. Dies kann passieren, wenn der Client und der Server nicht auf das Authentifizierungsprotokoll abgestimmt sind. Verwende die vom Server spezifizierte Methode (z.B. Basic, Bearer, API-Schlüssel) und überprüfe die korrekte Syntax in den Headern.

Serverantwort überprüfen#

Überprüfe den Antworttext auf Fehlermeldungen und sieh dir den WWW-Authenticate-Header für Authentifizierungsanweisungen an.

Anfrage überprüfen#

Stelle sicher, dass Endpunkt, Abfrageparameter und Host korrekt sind und dass die Ressource, auf die du zugreifst, eine Authentifizierung erfordert.

Token-Probleme überprüfen#

Dekodiere und überprüfe das Token (z.B. mit https://logto.io/jwt-decoder) auf Gültigkeit, Ablauf und Claims und vergleiche die Zielgruppe (aud) des Tokens mit den Anforderungen der API.

Wie kann ich einen 403 Forbidden-Fehler beheben#

Ein 403 forbidden error bedeutet normalerweise, dass der Autorisierungsprozess abgeschlossen wurde, der Zugriff jedoch verweigert wurde. Um diesen Fehler zu beheben, sollten folgende Bedingungen berücksichtigt werden:

Berechtigungen überprüfen#

Vergewissere dich, dass dein Konto, API-Schlüssel oder Token die erforderlichen Berechtigungen für die Ressource hat. Überprüfe, ob die Ressource auf bestimmte Rollen oder Gruppen beschränkt ist.

Sicherstellen, dass die Authentifizierung korrekt ist#

Stelle sicher, dass du ordnungsgemäß authentifiziert bist (z.B. mit einem gültigen Token oder Anmeldedaten).

Überprüfe die vom Server geforderte Authentifizierungsmethode.

Ressource validieren#

Stelle sicher, dass die angeforderte Ressource existiert und dass du darauf zugreifen kannst. Wenn du APIs verwendest, überprüfe die Endpunktanforderungen in der Dokumentation.

IP- oder Standortblockierung überprüfen#

Überprüfe, ob deine IP-Adresse oder dein geografischer Standort vom Server eingeschränkt wird.

Serverrichtlinien überprüfen#

Stelle sicher, dass die angeforderte Aktion nicht gegen serverseitige Regeln oder Richtlinien verstößt (z.B. Zugriff auf eine Nur-Lese-Ressource).

Serverantwort überprüfen#

Überprüfe den Antworttext auf Details, die den Grund für den 403-Fehler erklären.

Kann eine einzelne Anfrage sowohl 401- als auch 403-Statuscodes zurückgeben#

Nein, eine einzelne HTTP-Anfrage kann nicht gleichzeitig die Statuscodes 401 Unauthorized und 403 Forbidden zurückgeben, da eine HTTP-Antwort nur einen Statuscode enthalten kann.

Der praktische Nutzen der Fehlercodes 401 und 403 bei Authentifizierung und Autorisierung#

In der modernen Anwendungsentwicklung sind 401 Unauthorized und 403 Forbidden zwei HTTP-Statuscodes, auf die Entwickler häufig stoßen. Auch wenn sie ähnlich erscheinen mögen, sind ihre Bedeutungen und Anwendungsfälle deutlich unterschiedlich. Um ihre Unterschiede zu klären, untersucht dieser Artikel praktische Beispiele für diese Codes in Szenarien wie Authentifizierung, Autorisierung, Multi-Tenancy und Multi-Faktor-Authentifizierung (MFA).

1. Login-Szenario: Ein Benutzer versucht, auf eine geschützte Seite zuzugreifen, ohne sich anzumelden oder gültige Anmeldedaten bereitzustellen. Der Server antwortet und gibt einen 401 Unauthorized-Fehler aus: „Du musst dich einloggen oder gültige Anmeldedaten angeben, um auf diese Seite zuzugreifen.“
2. Zugriffssteuerungsszenario: Derselbe Benutzer loggt sich erfolgreich ein, versucht jedoch, auf eine nur für Administratoren zugängliche Seite zuzugreifen, ohne die erforderliche Administratorrolle zu haben. Der Server antwortet und gibt einen 403 Forbidden-Fehler aus: „Du bist eingeloggt, aber du hast keine Berechtigung, auf diese Seite zuzugreifen.“
3. Multi-Tenant-Szenario: Derselbe Benutzer loggt sich ein, gehört jedoch zu Tenant A und versucht, auf eine Ressource in Tenant B zuzugreifen, auf die er keinen Zugriff hat. Der Server antwortet und gibt einen 403 Forbidden-Fehler aus: „Du bist authentifiziert, aber du hast keine Berechtigung, auf diese Ressource in Tenant B zuzugreifen.“
4. MFA-Szenario: Ein Benutzer versucht, sich einzuloggen, hat jedoch die erforderliche Multi-Faktor-Authentifizierung (MFA) nicht abgeschlossen. Der Server antwortet und gibt einen 401 Unauthorized-Fehler aus: „Die Authentifizierung ist unvollständig. Bitte schließe die MFA ab, um fortzufahren.“

Verwendung von Logto als Authentifizierungs- und Autorisierungsanbieter#

Logto ist in erster Linie ein Authentifizierungsanbieter und bietet wichtige Methoden wie passwortloses Login, E-Mail und Passwort, MFA, Enterprise SSO und soziale Anmeldung, die alle auf offenen Standards wie OIDC, OAuth 2.0 und SAML basieren.

Logto Cloud bietet auch wesentliche Autorisierungsfunktionen, einschließlich Rollenbasierter Zugriffskontrolle (RBAC), Organisationen (Multi-Tenancy) und Benutzerdefinierten Tokenansprüchen, um eine Vielzahl von Autorisierungsanforderungen zu erfüllen.