Basic-Auth-Header-Generator

Geben Sie Benutzername und Passwort ein, um den Header Authorization: Basic und einen sofort ausführbaren curl-Befehl zu erhalten, oder fügen Sie einen vorhandenen Header ein, um die darin enthaltenen Zugangsdaten zu sehen.

Authorization-Header
curl-Befehl

Vorhandenen Header dekodieren

Läuft vollständig in Ihrem Browser. Es wird nichts hochgeladen.

Anleitung

  1. Geben Sie den Benutzernamen und das Passwort ein.
  2. Kopieren Sie den erzeugten Authorization-Header in Ihren Client oder testen Sie die Anfrage mit dem curl-Befehl.
  3. Um einen vorhandenen Header zu lesen, fügen Sie ihn im Bereich „Vorhandenen Header dekodieren“ ein. Benutzername und Passwort werden dann angezeigt.

So funktioniert die HTTP-Basic-Authentifizierung

Die Basic-Authentifizierung ist in RFC 7617 definiert. Ist eine Ressource geschützt, antwortet der Server mit 401 Unauthorized und einem Header WWW-Authenticate: Basic realm="...". Der Client verbindet daraufhin Benutzername und Passwort mit einem Doppelpunkt, kodiert das Ergebnis als Base64 und sendet es mit jeder Anfrage:

Authorization: Basic base64(username ":" password)

# Beispiel aus RFC 7617: Benutzer "Aladdin", Passwort "open sesame"
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Browser wickeln diesen Austausch selbst ab und zeigen einen Anmeldedialog an, während Skripte und API-Clients den Header meist schon mit der ersten Anfrage senden, ohne auf die Aufforderung (Challenge) des Servers zu warten. Da der Doppelpunkt die beiden Werte trennt, darf der Benutzername keinen enthalten, das Passwort hingegen schon. Ein Server kann seiner Challenge charset="UTF-8" hinzufügen, um anzukündigen, dass Zugangsdaten mit Nicht-ASCII-Zeichen in UTF-8 erwartet werden.

Base64 ist keine Verschlüsselung

Der Header wirkt unleserlich, doch jeder, der ihn sieht, kann das Passwort in Sekunden wiederherstellen, mit dem Decoder auf dieser Seite oder mit jedem anderen Base64-Decoder. Basic-Authentifizierung ist nur über HTTPS vertretbar, wo TLS den Header bei der Übertragung verschlüsselt. Beachten Sie außerdem:

  • die Zugangsdaten werden mit jeder Anfrage mitgesendet, sodass schon eine einzige unverschlüsselte HTTP-Anfrage sie preisgibt;
  • Proxys, Load Balancer und Debugging-Tools protokollieren den Header Authorization unter Umständen, wenn sie nicht ausdrücklich anders konfiguriert sind;
  • Browser merken sich eingegebene Zugangsdaten, bis sie geschlossen werden, und es gibt keine standardisierte Möglichkeit zum Abmelden.

Für öffentliche APIs eignen sich widerrufbare API-Token oder OAuth besser. Für interne Tools, Staging-Websites und Server-zu-Server-Aufrufe über TLS bleibt die Basic-Authentifizierung eine vernünftige Wahl.

Den Header aus Code senden

# curl erzeugt den Header selbst
curl -u 'user:password' https://api.example.com/

// JavaScript fetch (btoa verarbeitet nur Latin-1-Zeichen)
fetch(url, { headers: { Authorization: 'Basic ' + btoa('user:password') } })

# Python requests
requests.get(url, auth=('user', 'password'))

Vermeiden Sie es, Zugangsdaten in die URL einzubetten, wie bei https://user:password@host/. RFC 3986 rät von dieser Form ab, sie landet im Browserverlauf und in Serverprotokollen, und moderne Browser schränken sie ein.

Häufig gestellte Fragen

Wie dekodiere ich einen Basic-Auth-Header?

Fügen Sie den Header im Bereich „Vorhandenen Header dekodieren“ ein, und Benutzername und Passwort erscheinen sofort. Jeder Base64-Decoder liefert dasselbe Ergebnis, und genau deshalb darf der Header nur über HTTPS übertragen werden.

Darf das Passwort einen Doppelpunkt enthalten?

Ja. Der Server trennt den dekodierten Wert am ersten Doppelpunkt, alles danach gehört also zum Passwort. Der Benutzername darf dagegen keinen Doppelpunkt enthalten.

Ist die HTTP-Basic-Authentifizierung sicher?

Über HTTPS und mit einem starken, einmaligen Passwort schützt sie die Zugangsdaten bei der Übertragung, doch diese werden mit jeder Anfrage gesendet und können nicht wie ein Token ablaufen. Verwenden Sie sie niemals über unverschlüsseltes HTTP.

Warum schlägt die Anmeldung bei Passwörtern mit Umlauten, Akzenten oder nicht-lateinischen Zeichen fehl?
Client und Server verwenden möglicherweise unterschiedliche Zeichenkodierungen. Nach RFC 7617 kann der Server charset="UTF-8" angeben; fehlt diese Angabe, gehen ältere Server unter Umständen von ISO-8859-1 aus und vergleichen andere Bytes.
Wird mein Passwort irgendwohin gesendet?

Nein. Der Header wird per JavaScript in Ihrem Browser erzeugt, und es wird nichts übertragen. Verwenden Sie trotzdem Test-Zugangsdaten, wenn Sie einen erzeugten curl-Befehl mit anderen teilen.