Erfahre, was Bearer-Tokens sind, wie sie in OAuth 2.0 und JWT funktionieren, worin der Unterschied zu Access-Tokens liegt und welche Best Practices es gibt.
Hinter fast jedem modernen App-Login oder API-Request verbirgt sich ein stiller Arbeitspferd: das Bearer-Token. Du bemerkst es vielleicht nicht, aber es ist jedes Mal dabei, wenn du Dienste verbindest, dich anmeldest oder Daten aus der Cloud abrufst.
Diese Anleitung erklärt, was Bearer-Tokens leisten, warum sie wichtig sind und wie du sie sicher handhabst.
Ein Bearer-Token ist ein Datenstück, meistens eine Zeichenkette, das nachweist, dass der Besitzer berechtigt ist, auf eine Ressource zuzugreifen. Das Entscheidende: Wer auch immer das Token trägt, kann es benutzen, ohne zusätzliche Nachweise zu erbringen.
Denke an eine Bordkarte beim Fliegen. Sobald du sie in der Hand hast, kannst du die Sicherheitskontrolle passieren und ins Flugzeug steigen. Niemand bittet dich erneut um einen Ausweis, wenn die Bordkarte gültig ist. Genauso erlaubt ein Bearer-Token deiner Anwendung, „an Bord der API zu gehen“, ohne jedes Mal deine Identität zu prüfen.
Beispielsweise musst du nach dem Einloggen in Spotify auf deinem Handy nicht jedes Mal dein Passwort eingeben, wenn du einen Song abspielst. Stattdessen speichert die App ein Bearer-Token, das Spotifys Servern signalisiert: „Diese Anfrage kommt von einem autorisierten Benutzer.“
Der Ablauf von Bearer-Tokens lässt sich in ein paar Schritte unterteilen:
Benutzer meldet sich an
Angenommen, du loggst dich mit Benutzernamen und Passwort bei einer Banking-App ein.
Identity-Provider stellt ein Token aus
Nach der Überprüfung sendet der Authentifizierungsserver ein Bearer-TOKEN zurück. Das könnte so aussehen:
Client verwendet das Token
Bei jeder Aktion wie „Kontostand abfragen“ oder „Geld überweisen“ fügt die App das Token in die HTTP-Anfrage ein:
API validiert es
Der Server prüft, ob das Token noch gültig und nicht abgelaufen ist und ob es die richtigen Berechtigungen enthält (z. B. read:balance oder write:transfer).
Zugriff gewährt
Wenn alles passt, sendet der Server die angeforderten Informationen zurück.
Dieses Modell wird häufig von Diensten wie den GitHub-APIs genutzt, bei denen sich Entwickler mit einem Bearer-Token authentifizieren, statt ständig Zugangsdaten einzugeben.
Bearer-Tokens wurden populär, weil sie typische Probleme der Websicherheit lösen. Anders als serverbasierte Sessions muss nicht für jeden eingeloggten Benutzer ein Datensatz gespeichert werden. Das Token selbst enthält genug Informationen, damit der Server Anfragen validieren kann.
Gerade in einer Microservices-Architektur, in der Dutzende Services miteinander kommunizieren, wäre zentrales Session-Management zu komplex und ineffizient. Mit Bearer-Tokens kann jeder Service Anfragen eigenständig prüfen – das macht das System leichtgewichtig und skalierbar.
Ein konkretes Beispiel: Slacks APIs stützen sich stark auf Bearer-Tokens. Wenn du einen Slack-Bot baust, erhältst du ein Token, damit dein Bot Slacks Endpunkte ohne eigene Session je Benutzer ansprechen kann.
Viele Bearer-Tokens sind als JWTs (JSON Web Tokens) realisiert. Diese Token sind kodierte Zeichenketten, die Informationen über Benutzer und deren Berechtigungen enthalten.
Schauen wir uns einen Beispiel-JWT an:
Das bedeutet:
sub: Der Benutzer, bzw. die eindeutige Benutzer-ID.name: Name des Benutzers.iat: Ausstellungszeitpunkt (issued at timestamp).exp: Ablaufzeitpunkt (ab wann das Token ungültig ist).scope: Die Berechtigungen – in diesem Fall kann die App Nachrichten lesen und schreiben.In der Praxis: Hätte Janes Token nur den Scope read:messages, könnte die App ihre Nachrichten abrufen, aber keine neue in ihrem Namen senden.
Bearer-Tokens und Access-Tokens werden oft verwechselt, da die Begriffe häufig zusammen fallen. Tatsächlich sind sie verwandt, aber nicht identisch.
Ein Access-Token ist eine Berechtigung, die die Autorisierung eines Benutzers repräsentiert. Es enthält Informationen wie:
Man kann es mit einem Erlaubnisschein vergleichen, unterschrieben vom Schulleiter. Er signalisiert dem Lehrer (der API), dass du am Ausflug teilnehmen darfst (auf die Ressource zugreifen).
Zum Beispiel: Melde dich bei einem Cloud-Speicherdienst an, erhältst du ein Access-Token mit dem Scope read:files. Das Token sagt der Speicher-API: „Dieser Benutzer darf Dateien lesen, aber nicht löschen.“
Ein Bearer-Token ist eine Art Access-Token. Das Wort Bearer beschreibt, wie das Token verwendet wird: Wer es präsentiert, kann damit Ressourcen nutzen, ohne sich weiter auszuweisen.
Anders gesagt:
Es gibt andere Token-Typen, wie Holder-of-Key-Tokens. Die verlangen vom Client zusätzlich einen kryptografischen Schlüssel nachzuweisen. Bearer-Tokens überspringen diese Hürde – was sie einfacher, aber bei Diebstahl auch riskanter macht.
<token>-Header verwendest.Das heißt: Wo in OAuth-Tutorials „Access-Token“ steht, ist fast immer ein Bearer-Token gemeint – außer es wird explizit anders beschrieben.
Zur Übersicht ein Vergleich von Bearer-Tokens mit anderen gängigen Token-Typen:
Bearer- und Access-Tokens sind also keine Gegensätze – sie überschneiden sich:
Die Validierung eines Bearer-Tokens trennt deine API von unberechtigtem Zugriff. Bei JWTs geht das lokal und schnell: Die API kann das Token prüfen, ohne den Aussteller zu kontaktieren.
Nutze diese Liste z. B. beim Einbinden in einen API-Gateway oder eine Middleware.
Signatur
Prüfe die Signatur gemäß Algorithmus im Header (z. B. RS256). Hole dir den JWKS-Endpunkt (=Keyset) des Ausstellers, finde den passenden Key anhand des kid und cache ihn.
Issuer (iss)
Vergleiche das Feld iss mit deiner vertrauenswürdigen Aussteller-URL – exakt und mit korrektem Schema.
Audience (aud)
Stelle sicher, dass das Token für deine API bestimmt ist (z.B. https://api.example.com oder eine logische Kennung).
Ablauf (exp) und Nicht-vorher (nbf)
Lehne abgelaufene Token ab. Respektiere nbf, damit ein Token nicht vor Startzeit nutzbar ist. Kleine Zeitsprünge von 30–60 Sekunden tolerieren.
Ausstellungszeitpunkt (iat)
Gut zum Debuggen, z. B. um sehr alte Token in strengen Setups abzulehnen.
Token-Typ
Stelle sicher, dass es ein Access-Token ist. Einige Provider setzen typ: "at+jwt" oder ähnlich. Akzeptiere keine ID-Tokens für API-Zugriff.
Scopes / Berechtigungen
Lese Scope- oder Optionsfelder (z. B. Permissions, Rollen). Erzwinge Minimalprinzip pro Endpoint.
Subject (sub)
Die feste User- oder Client-ID. Nutze sie für Ressourcenzuordnung und Auditing.
Replay und Revocation (optional, aber klug)
Für sensible Endpunkte: Halte eine Deny-Liste für kurze Zeit (z. B. nach Logout oder vermutetem Diebstahl von jti-Werten) oder prüfe, ob eine Session noch gültig ist.
Weil Bearer-Tokens nach dem Prinzip „wer es hat, kann es nutzen“ funktionieren, solltest du sie wie Hausschlüssel behandeln. Wer deinen Schlüssel stiehlt, kann deine Tür öffnen, bis du das Schloss wechselst.
Typische Gefahren sind:
Zu echten Datenlecks kam es z. B., wenn Entwickler versehentlich Bearer-Tokens in öffentliche GitHub-Repos eincheckten – Angreifer scannen gezielt danach, um unbefugt Systeme zu übernehmen.
Um Bearer-Tokens sicher zu verwenden, solltest du die folgenden Best Practices beachten. Hier ein Überblick mit Beispielen:
Immer HTTPS verwenden
Ein Token per HTTP über das Café-WLAN zu senden, ist fahrlässig – jeder im Netzwerk könnte das Token abgreifen und sich als dich anmelden.
Kurzlebige Access-Tokens nutzen
Die meisten Plattformen geben Token mit ca. einer Stunde Lebenszeit aus. Googles OAuth-Tokens etwa laufen nach einer Stunde ab und müssen dann erneuert werden.
Refresh-Tokens vorsichtig einsetzen
Mit einem Refresh-Token erhältst du neue Access-Tokens, ohne dich erneut einloggen zu müssen. Es sollte aber immer sicher gespeichert werden (z. B. verschlüsselt auf dem Server, nie im Client, nie im Browser).
Token auf minimal nötige Berechtigungen beschränken
Wenn deine App nur einen Kalender lesen muss, beantrage kein write:calendar. So minimierst du den potentiellen Schaden bei Diebstahl.
Token widerrufen, wenn nötig
Viele SaaS-Apps bieten eine Übersicht für aktive Sessions und die Möglichkeit, sie zu entziehen. Bei GitHub etwa kannst du Personal-Access-Tokens jederzeit widerrufen.
Nutzung überwachen
Wenn du die Nutzung von Tokens loggst, fällt verdächtiges Verhalten sofort auf. Wird z. B. dasselbe Token kurz nacheinander aus London und New York genutzt, ist das ein Alarmzeichen.
Ein Vergleich von Bearer-Tokens mit anderen Ansätzen ist sinnvoll:
Cookies & Sessions
Klassische Webseiten nutzen serverseitige Sitzungen, die per Cookie identifiziert werden. Das funktioniert mit Browser-Apps gut, ist für APIs oder Mobile Apps aber weniger effizient. Desktop-Logins bei Facebook laufen z. B. vor allem über Cookies, während Mobile-APIs auf Tokens setzen.
API-Keys
Ein API-Key ist ein statischer String, der die Anwendung authentifiziert, nicht den Benutzer. Ein Wetter-App nutzt einen API-Key, um sich Daten zu holen – der Server weiß nicht, welcher Benutzer konkret anfragt. Bearer-Tokens können Benutzerdaten mitführen und sind vielseitiger.
Mutual TLS (mTLS)
Manche Hochsicherheits-Systeme verlangen Zertifikate von Client und Server. Sehr sicher, aber schwer im großen Stil umzusetzen. Für die meisten SaaS-Plattformen bieten Bearer-Tokens die beste Balance aus Sicherheit und Komfort.