Authorization

Verwendung

Der Anfrage-Header Authorization verschafft Zugriff auf eine geschützte Ressource und wird typischerweise gesendet, nachdem der Client darüber informiert wurde, dass der Zugriff eingeschränkt ist. Nach dem Empfang einer HTTP-Antwort 401 Unauthorized vom Server, die den Header WWW-Authenticate enthält, übermittelt der Client seine Zugangsdaten beispielsweise auf diese Weise.

Hinweis

Browser entfernen den Authorization-Header, wenn eine Anfrage zu einem anderen Origin weitergeleitet wird. Das verhindert ein Durchsickern der Zugangsdaten, wenn eine Weiterleitung auf einen Drittanbieter-Server zeigt. Dieses Verhalten ist im WHATWG Fetch Standard definiert und wird von allen modernen Browsern unterstützt. Anwendungen, die sich über Cross-Origin-Weiterleitungen hinweg auf Authorization-Header verlassen, müssen die erneute Authentifizierung am endgültigen Ziel selbst behandeln. Werkzeuge wie curl, Python Requests und der HTTP-Client von Go folgen derselben Konvention.

authentication-scheme

Die authentication-scheme ist eine obligatorische Direktive, begleitet von optionalen schemaspezifischen Parametern. Das Schema legt das Kodierungsverfahren für die Zugangsdaten fest. Gängige Ansätze sind Basic, Bearer, Digest und Negotiate.

Beispiel

In diesem Beispiel verwendet der Client das Authentifizierungsschema Basic. Als erforderlicher Parameter sind die Zugangsdaten ein base64-kodiertes username:password-Paar.

Authorization: Basic RXhhbXBsZTphaQ==

Ein Bearer-Token ist bei OAuth-2.0-APIs üblich. Das Token ist eine undurchsichtige Zeichenkette oder ein von einem Autorisierungsserver ausgestelltes, signiertes JWT.

Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

Fehlersuche

Fehlgeschlagene Authentifizierungen zeigen sich häufig als unerwartete 401-Antworten oder als stillschweigend verworfene Zugangsdaten.

Zugangsdaten werden bei Cross-Origin-Weiterleitung entfernt. Browser und HTTP-Clients entfernen den Authorization-Header, wenn eine Anfrage zu einem anderen Origin weitergeleitet wird. Die Lösung besteht darin, die Zugangsdaten direkt an das endgültige Ziel zu senden oder sich nach Abschluss der Weiterleitung erneut zu authentifizieren. Prüfen Sie Weiterleitungsketten mit curl -L -v, um festzustellen, an welcher Stelle der Header verschwindet.

Base64-Kodierungsfehler bei der Basic-Authentifizierung. Die kodierte Zeichenkette muss genau einen Doppelpunkt enthalten, der Benutzername und Passwort trennt. Ein fehlender Doppelpunkt oder ein doppelt kodierter Wert erzeugt ein unleserliches Token, das der Server ablehnt. Überprüfen Sie den Rohwert mit echo -n “user:pass” | base64 und vergleichen Sie ihn mit dem in der Anfrage gesendeten Header-Wert.

Bearer-Token abgelaufen oder fehlerhaft. Tokens tragen einen Ablauf-Claim, und Server lehnen abgelaufene Tokens mit 401 ab. Dekodieren Sie ein JWT auf jwt.io oder mit echo "" | base64 -d, um das Feld exp zu prüfen. Die Logik zur Token-Erneuerung muss laufen, bevor das Token abläuft, und nicht erst, nachdem der Server die Anfrage abgelehnt hat.

401-Schleife, wenn der Server WWW-Authenticate weglässt. Der Server antwortet mit 401, schließt den Header WWW-Authenticate jedoch nicht ein und lässt den Client damit ohne Hinweis auf das erwartete Schema zurück. Prüfen Sie die Antwort-Header mit curl -I https://example.re/resource und stellen Sie sicher, dass die Serverkonfiguration den Header enthält. In nginx fügt die Direktive auth_basic den Header automatisch hinzu. Eigene Backends müssen den Header explizit setzen.

CORS-Preflight blockiert den Authorization-Header. Cross-Origin-Anfragen, die Authorization mitführen, lösen eine Preflight-OPTIONS-Anfrage aus. Der Server muss im Preflight mit Access-Control-Allow-Headers: Authorization antworten. Ein fehlender oder falscher Wert führt dazu, dass der Browser die Anfrage blockiert, bevor Zugangsdaten gesendet werden. Der Network-Tab der DevTools zeigt den Preflight als separaten OPTIONS-Eintrag an.

curl sendet Zugangsdaten an den falschen Endpunkt. Wird curl -H “Authorization: Bearer …” mit -L ausgeführt, folgt curl den Weiterleitungen, entfernt den Header aber bei Cross-Origin-Sprüngen. Verwenden Sie curl -v ohne -L, um den Header an genau den gewünschten Endpunkt zu senden, oder übergeben Sie —location-trusted, um die Weitergabe der Zugangsdaten über Weiterleitungen hinweg zu erzwingen (nur mit Vorsicht und ausschließlich bei vertrauenswürdigen Domains einsetzen).

Basic im Vergleich zu Bearer

Basic und Bearer sind die beiden häufigsten Authentifizierungsschemata und decken unterschiedliche Anwendungsfälle ab.

Basic sendet bei jeder Anfrage ein Base64-kodiertes username:password-Paar. Die Kodierung lässt sich trivial umkehren, weshalb HTTPS zwingend erforderlich ist. Die Zugangsdaten sind statisch und an ein Benutzerkonto gebunden, sodass ein kompromittiertes Passwort eine Änderung des Passworts selbst erfordert. Basic eignet sich gut für interne Werkzeuge und einfache Integrationen, bei denen die Token-Verwaltung unnötige Komplexität mit sich bringen würde.

Bearer verwendet undurchsichtige Tokens (oft JWTs), die von einem Autorisierungsserver ausgestellt werden. Tokens laufen ab, tragen auf Geltungsbereiche beschränkte Berechtigungen und lassen sich widerrufen, ohne das zugrunde liegende Passwort zu ändern. Bearer ist der Standardmechanismus für APIs und OAuth-2.0-Abläufe. Ein gestohlenes Token hat eine begrenzte Lebensdauer und einen begrenzten Geltungsbereich, was den Schadensradius im Vergleich zu einem durchgesickerten Passwort verringert.

Beide Schemata übertragen die Zugangsdaten im Klartext innerhalb des Header-Werts. Keines von beiden bietet für sich genommen eine Verschlüsselung. Unabhängig vom gewählten Schema ist HTTPS erforderlich.

Eine Cross-Origin-API-Anfrage mit einem Bearer-Token unter Verwendung der Fetch API.

fetch('https://api.example.re/data', {
  headers: {
    'Authorization': 'Bearer eyJhbGci...'
  }
})