Was sind Bearer-Tokens?

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.

Was ist ein Bearer-Token?#

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.“

Wie Bearer-Tokens in der Praxis funktionieren#

Der Ablauf von Bearer-Tokens lässt sich in ein paar Schritte unterteilen:

1. Benutzer meldet sich an

   Angenommen, du loggst dich mit Benutzernamen und Passwort bei einer Banking-App ein.

2. Identity-Provider stellt ein Token aus

   Nach der Überprüfung sendet der Authentifizierungsserver ein Bearer-TOKEN zurück. Das könnte so aussehen:

3. Client verwendet das Token

   Bei jeder Aktion wie „Kontostand abfragen“ oder „Geld überweisen“ fügt die App das Token in die HTTP-Anfrage ein:

4. 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).

5. 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.

Warum Bearer-Tokens populär wurden#

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.

Was steckt in einem Bearer-Token?#

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 vs. Access-Tokens: Wo liegt der Unterschied?#

Bearer-Tokens und Access-Tokens werden oft verwechselt, da die Begriffe häufig zusammen fallen. Tatsächlich sind sie verwandt, aber nicht identisch.

Access-Token: Der „Erlaubnisschein“#

Ein Access-Token ist eine Berechtigung, die die Autorisierung eines Benutzers repräsentiert. Es enthält Informationen wie:

• Wer der Benutzer ist (seine ID)
• Was er tun darf (Scopes/Berechtigungen)
• Wann das Token abläuft

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.“

Bearer-Token: Das „Übermittlungsformat“#

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:

• Alle Bearer-Tokens sind Access-Tokens.
• Aber nicht alle Access-Tokens sind Bearer-Tokens.

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.

Beispiel aus der Praxis#

• Access-Token (generisch): Kann ein signiertes Datenstück sein, das manchmal einen privaten Schlüssel auf Client-Seite fordert.
• Bearer-Token (spezifisch): Die meisten OAuth 2.0-Implementierungen nutzen Access-Tokens im Bearer-Format, z. B. liefert Google OAuth ein Access-Token, das du im Authorization: Bearer <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.

Andere Token-Typen im Vergleich#

Zur Übersicht ein Vergleich von Bearer-Tokens mit anderen gängigen Token-Typen:

• Refresh-Token: Dient dazu, ein neues Access-Token zu erhalten, wenn das alte abläuft. Refresh-Tokens sind normalerweise keine Bearer-Tokens, weil sie sicher mit dem Autorisierungsserver ausgetauscht und nicht direkt an APIs gesendet werden.
• ID-Token: Dient der Authentifizierung, nicht der Autorisierung. Es enthält Identitätsinformationen (wie E-Mail, Name oder Benutzer-ID). Je nach System kann ein ID-Token auch ein Bearer-Token sein, aber sein Zweck unterscheidet sich vom Access-Token.
• API-Key: Eine einfache Form von Zugangsdaten, die nur die aufrufende Anwendung identifiziert. Oft funktionieren API-Keys wie Bearer-Tokens, weil jeder, der den Key besitzt, die API aufrufen kann.

Bearer- und Access-Tokens sind also keine Gegensätze – sie überschneiden sich:

• Die meisten Access-Tokens sind Bearer-Tokens.
• Ein Bearer-Token beschreibt die Art der Nutzung (Vorzeigen, um Zugriff zu erhalten).
• Im Alltag werden „Access-Token“ und „Bearer-Token“ häufig gleichbedeutend verwendet, auch wenn sie in der Technik unterschiedliche Schwerpunkte setzen.

Wie prüft man ein JWT-Access-Token (Bearer-Token)?#

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.

Der Kern der Prüfung#

1. Token parsen.
2. Signatur mit dem öffentlichen Schlüssel des Ausstellers verifizieren.
3. Standard-Claims prüfen: Aussteller, Empfänger, Ablaufzeit, nicht-vorher.
4. Eigene App-Regeln wie Scopes, Rollen und Token-Typ durchsetzen.
5. Optional: Token-Revoke-Listen oder Session-State bei sensiblen Aktionen konsultieren.

Validation-Checkliste (JWT)#

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.

Sicherheitsrisiken von Bearer-Tokens#

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:

• Token-Diebstahl – Kommt ein Angreifer an das lokal gespeicherte Token (z. B. in browser localStorage), kann er den Benutzer imitieren. 2018 wurden z. B. Browser-Addons dabei erwischt, die Token aus dem LocalStorage gestohlen und verkauft haben.
• Replay-Attacken – Schnappt ein Angreifer ein Token ab, kann er es wiederverwenden, solange es gültig ist. Ohne HTTPS ist das erschreckend leicht.
• Lang lebende Token – Je länger ein Token gültig bleibt, desto größer das Zeitfenster für Angreifer.

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.

Best Practices für den Einsatz von Bearer-Tokens#

Um Bearer-Tokens sicher zu verwenden, solltest du die folgenden Best Practices beachten. Hier ein Überblick mit Beispielen:

1. 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.

2. 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.

3. 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).

4. 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.

5. 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.

6. 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.

Bearer-Tokens vs. andere Authentifizierungsmethoden#

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.

Wichtigste Punkte#

• Bearer-Tokens sind einfach, aber wirkungsvoll: Wer sie besitzt, kann auf die Ressource zugreifen.
• Sie sind weit verbreitet in OAuth 2.0 und OIDC-Flows, vor allem bei APIs und Mobile-Apps.
• Sicherheit hängt von ihrem Management ab: kurze Gültigkeit, Scopes, HTTPS und Möglichkeit zum Widerruf sind entscheidend.
• Sie sind nicht immer die beste Wahl, aber in den meisten SaaS- und API-Kontexten bieten sie einen guten Mittelweg zwischen Sicherheit und Komfort.