HTTP Basic Auth

Was ist HTTP Basic Auth?

Sobald man im Internet auf sensible Informationen, Daten und Verzeichnisse zugreifen möchte, wird vom Server in der Regel eine entsprechende Autorisation gefordert. Um eine Freigabe zu erreichen, wird dem Besucher ein einfacher Eingabedialog für Benutzername und Passwort angeboten. Mit diesen Informationen kann der Server den Benutzer idealerweise erkennen und entsprechend freigeben. Für dieses Szenario stehen aber verschiedene Sicherheits- und Authentifizierungslevel zur Verfügung.

In den Anfängen des Internetzeitalters wurden diese Authentifizierungen relativ simpel gestaltet. Unter dem Begriff HTTP Basic Auth ist demnach ein sehr vereinfachtes Verfahren bekannt, dass einem Benutzer einen vorgefertigten und schlichten Dialog zur Eingabe seiner Benutzerdaten auffordert. Diesen Dialog findet man aber nicht nur in Browsern, auch beispielsweise Windows zaubert diesen Anmeldedialog immer noch beim Zugriff auf eine Netzwerkressource hervor. Wie funktioniert diese einfache Anmeldung aber nun im Detail? Dies möchten wir in den folgenden Abschnitten vorstellen.

Die Funktionsweise von Basic Auth

Auch wenn es inzwischen wesentlich fortschrittlichere Anmeldeverfahren wie beispielsweise OAuth 2.0 zur Authentifizierung von Benutzern gibt, wird mit HTTP Basic Auth immer noch ein Standard-Verfahren angeboten. Die Funktionsweise ist dabei sehr einfach und transparent aufgebaut. Sobald Sie im Webbrowser eine gültige URL eingetragen und abgesendet haben, prüft der Server, ob Sie als Benutzer Zugriff auf die angeforderte URL bekommen können. Wenn die Ressource geschützt ist, wird der Server Ihrem Browser einen entsprechenden Statuscode (im Falle einer nötigen Autorisierung ist das der Fehlercode 401) mitteilen und eine Authentifizierung anfordern. Der Server-Response-Header sieht dann beispielsweise wie folgt aus:

HTTP/1.1 401 Unauthorized
Date: Wed, 12 Dec 2018 12:16:21 GMT
WWW-Authenticate: Basic realm="User Profile Login"
Content-Length: 0
...

In diesem Server-Response wird über den Schlüssel „WWW-Authenticate:“ und dem folgenden Parameter „Basic“ das Standard-Authentifizierungsverfahren angefordert. Der Parameter „realm=“ liefert hier noch eine Kurzbeschreibung zur Fehlermeldung. Der Wert kann beliebig gesetzt werden und beschreibt in diesem Beispiel einfach nur den Bereich, zu dem die Fehlermeldung aufgeworfen wurde. Hier wurde offensichtlich versucht, sich mit einer URL direkt in einen durch Benutzerkonto geschützten Bereich einzuloggen.

Auf diese Serverantwort hin öffnet der Browser jetzt entweder einen vordefinierten Eingabedialog für Benutzernamen und Passwort oder verwendet bereits im Browser zuvor eingetragene und gespeicherte Benutzerdaten. Diese werden dann erneut und verschlüsselt mit einem neuen Header zur Berechtigungsanforderung an den Server zurückgesendet. Der Request-Header hat dabei folgendes beispielhaftes Aussehen:

GET /securefiles/ HTTP/1.1
Host: www.dataliquid.com
Authorization: Basic TWFuZnJlZCBBMnA3IzU/MUgzMw==
...

Mit dieser Nachricht sendet der Browser die Anmeldedaten an den Server zurück. Dem Parameter „Authorization:“ wird dabei der Wert „Basic“ für eine Standard-Autorisierung mitgegeben. Der darauffolgende Wert „TWFuZnJlZCBBMnA3IzU/MUgzMw==“ repräsentiert die Anmeldedaten in einer Base64-codierten Verschlüsselung aus Benutzername „Manfred“ und dem Passwort „A2p7#5?1H33“. Mit diesen Informationen kann Sie der Server nun korrekt anmelden und öffnet die angeforderte URL im Browser.

Neben dem hier gezeigten Authentifizierungsschema „Basic“ kann der Server dem Client noch weitere Schemata anbieten:

  • Anonym: enthält keine Authentifizierungsinformationen und dient daher als universelle Freigabe für alle Anfragen.

  • Basic: wurde im obigen Beispiel als Standard-Authentifizierung vorgestellt. Hier muss eine Kombination aus Benutzername und Passwort vergeben sein.

  • Digest: biete als Ersatz für das Basic-Schema eine Hashwert-basierte Authentifizierung in einem mehrfachen Austauschverfahren zwischen Client und Server.

  • NTLM: verwendet eine nochmals sicherere Variante der Digest-Authentifizierung und verwendet die Windows-Anmeldeinformationen zur Freigabe.

  • Negotiate: bietet eine automatisierte Auswahl von entweder dem NTLM-Schemata oder dem Kerberos-Protokoll. Die Auswahl wird automatisch und je nach Verfügbarkeit ausgewählt.

Fazit

Auch wenn heute bereits wesentlich modernere und sicherere Anmeldeverfahren wie OAuth2 oder Single-Sign-On als Standard eingesetzt werden, ist mit HTTP Basic Auth dennoch ein Standard-Anmeldeverfahren für die einfache Nutzung vorhanden. Der Vorteil ist hierbei auch nicht zu unterschätzen: Standard-Sicherheitsfaktoren, schnelle Reaktionszeiten, geringer Overhead und auf nahezu jedem Server-/Clientsystem als Standard implementiert. Die Anwendung in eigenen Client-/Serverumgebungen ist gut dokumentiert und einfach zu realisieren.

Dennoch raten wir grundsätzlich zu den neueren Methoden OAuth2 und Single Sign-On. Die unkomplizierte Nutzung von OAuth2 bei Nutzern steht dabei im Vordergrund. Diese können sich mit einem beispielsweise bei Google vorhandenen Konto und dessen Anmeldeinformationen schnell und sicher auf vielen Plattformen anmelden. Das Gleiche gilt auch für Single-Sign-On. Benutzer möchten sich heute einfach keine dutzende von Benutzernamen und Kennwörter für eine Autorisierung bei Webdiensten und Anbietern merken müssen.

Nach oben