HTTP Basic Authentication ist eine der ältesten und einfachsten Methoden, um Zugriff auf eine Webressource zu schützen. Trotz – oder gerade wegen – ihrer Schlichtheit begegnet sie dir ständig: bei internen APIs, geschützten Verzeichnissen, CI/CD-Pipelines oder Webhooks. Dieser Artikel erklärt, wie der dazugehörige Authorization-Header aufgebaut ist, welche Rolle Base64 spielt und worauf du bei der Sicherheit achten musst.
Wie funktioniert Basic Auth?
Das Prinzip ist im Standard RFC 7617 definiert und denkbar einfach. Der Client schickt bei jeder Anfrage Benutzername und Passwort mit, verpackt in einem HTTP-Header:
- Benutzername und Passwort werden mit einem Doppelpunkt verbunden: benutzer:passwort.
- Diese Zeichenkette wird per Base64 codiert.
- Das Ergebnis landet im Header: Authorization: Basic dXNlcjpwYXNzd29ydA==.
Fehlt der Header, antwortet der Server mit dem Statuscode 401 Unauthorized und dem Header WWW-Authenticate: Basic. Der Browser zeigt daraufhin den bekannten Login-Dialog an. Mit dem Basic Auth Generator gibst du Benutzername und Passwort ein und erhältst den fertigen Authorization-Header zum Kopieren – ideal für API-Tests oder Konfigurationsdateien.
Base64 ist keine Verschlüsselung
Der häufigste Irrtum: Viele halten die Base64-Zeichenkette für ein verschlüsseltes Passwort. Das ist sie nicht. Base64 ist lediglich eine reversible Codierung, die beliebige Bytes in druckbare ASCII-Zeichen umwandelt, damit sie sicher durch HTTP-Header transportiert werden können. Jeder kann eine Base64-Zeichenkette in Sekunden zurückwandeln und Klartext-Benutzername und -Passwort lesen.
Daraus folgt die wichtigste Regel: Basic Auth darf niemals über unverschlüsseltes HTTP laufen. Nur über HTTPS/TLS sind die Zugangsdaten auf dem Transportweg geschützt, weil dann die gesamte Verbindung inklusive Header verschlüsselt ist.
Vor- und Nachteile von Basic Auth
Basic Auth überzeugt durch Einfachheit, hat aber klare Grenzen:
- Vorteil – einfach: kein Token-Handling, keine Sitzungsverwaltung, von praktisch jedem HTTP-Client und Server unterstützt.
- Vorteil – zustandslos: Jede Anfrage trägt ihre Credentials selbst, was sich gut für einfache APIs eignet.
- Nachteil – Credentials in jeder Anfrage: Benutzername und Passwort werden bei jedem Request mitgesendet, was die Angriffsfläche erhöht.
- Nachteil – kein sauberes Logout: Browser cachen die Anmeldedaten; ein echtes Abmelden ist umständlich.
- Nachteil – keine feingranularen Rechte: Es gibt nur Zugang oder kein Zugang, keine Scopes wie bei OAuth-Tokens.
Wann ist Basic Auth sinnvoll?
Trotz der Einschränkungen ist Basic Auth in vielen Szenarien völlig ausreichend: für interne Tools hinter HTTPS, zum schnellen Schützen einer Staging-Umgebung, für Server-zu-Server-Kommunikation oder als simpler Schutz für Webhook-Endpunkte. Wo es um öffentliche, nutzerorientierte Anwendungen mit Logout, Passwort-Reset und Rollen geht, greift man besser zu Sessions, JWTs oder OAuth 2.0.
Praktische Anwendung
Wenn du eine API testest oder einen Verzeichnisschutz in der Webserver-Konfiguration einrichtest, brauchst du den korrekten Header. Erzeuge ihn mit dem Basic Auth Generator direkt im Browser – nichts wird übertragen, alles läuft lokal. Da Basic Auth komplett auf Base64 aufbaut, lohnt sich auch ein Blick auf den allgemeinen Base64 Encoder Decoder, mit dem du beliebige Werte codieren und wieder lesbar machen kannst. Weitere Helfer für die Entwicklung findest du in der Übersicht der kotsch.tech Webtools.
Häufige Fragen
Ist Basic Auth unsicher?
Nicht grundsätzlich. Über HTTPS sind die Zugangsdaten auf dem Transportweg geschützt. Unsicher wird es nur, wenn man Basic Auth über unverschlüsseltes HTTP nutzt oder schwache Passwörter verwendet. Die Codierung selbst bietet keinen Schutz – die Sicherheit kommt allein von TLS.
Wie sieht der Header genau aus?
Er besteht aus dem Schlüsselwort, einem Leerzeichen und der Base64-Zeichenkette: Authorization: Basic <base64(user:passwort)>. Wichtig ist, dass zwischen Benutzer und Passwort ein Doppelpunkt steht und der gesamte String codiert wird.
Kann ein Passwort einen Doppelpunkt enthalten?
Das Passwort darf einen Doppelpunkt enthalten, der Benutzername jedoch nicht – sonst wäre die Trennung mehrdeutig. Der erste Doppelpunkt gilt immer als Trennzeichen, alles danach gehört zum Passwort.