Wer die Eintrittskarte in der Hand hat, kommt rein. Genau so prüft ein Server ein Bearer-Token – und das hat Folgen.

Erklärt wird hier, wie eine authentifizierte Anfrage über das Netz läuft. Die Situation kennt jeder, der einmal eine API oder eine App mit Login benutzt hat.

Zuerst sendet der Client beim Einloggen seine Zugangsdaten, etwa E-Mail und Passwort, an den Server. Der prüft sie und stellt im Erfolgsfall ein Zugriffstoken aus, also eine Art digitale Eintrittskarte. HTTP selbst ist zustandslos: Jede Anfrage steht für sich, und der Server erkennt einen Nutzer nur wieder, wenn Daten wie ein Token mitgesendet werden.

Dann schickt der Client das Token bei jeder weiteren Anfrage im Authorization-Header mit, nach dem Schema „Authorization: Bearer“ gefolgt vom Tokenwert. Bearer ist Englisch für Inhaber. Der Server prüft nur, ob ein gültiges Token vorliegt – nicht, wer die Anfrage eigentlich stellt.

Danach entscheidet der Server allein auf Basis dieses Headers. Wer das Token besitzt, darf damit arbeiten, wie ein Gast mit Garderobenmarke. Ein solches Token ist meist zeitlich begrenzt; anders als ein Passwort läuft es also bald ab.

Zuletzt kommt die Übertragung: Sie muss über TLS laufen, also über die verschlüsselte Variante von HTTP namens HTTPS. Nur dann ist der Header vor dem Mitlesen geschützt. Über offenes HTTP kann jeder im Netzpfad, etwa in einem offenen WLAN, das Token abfangen und anschließend selbst verwenden. Der Besitz allein reicht ja aus.

Bearer heißt nicht „berechtigte Person“, sondern „Inhaber“. Ohne HTTPS trägt jede Anfrage das Token offen im Klartext mit.

📌 Bearer-Token · Authorization-Header · TLS

📚 Webentwicklung von Grund auf · Tag 4 von 30
#HTTP #WebSecurity #webdev #api