Autor: amoerke

Was ist ein Token?

Ein Token kann von einer Partei an eine andere übergeben werden. Ein Personalausweis ist ein Token, das die Stadt an einen Bürger übergibt.

Was sind Bearer Token?

Die Gültigkeit eines Ausweises ist auf eine Person beschränkt. Bei einer Polizeikontrolle muss stets der eigene Ausweis vorgezeigt werden. Es gibt Tokens, die dieser Beschränkung nicht unterliegen. Ein Schlüssel kann einer Werkstatt übergeben werden, damit diese ein Auto entsperren können. Es genügt, im Besitz des Schlüssels zu sein, um die Türe zu öffnen. Der Begriff Bearer bedeutet auf Deutsch Träger oder Inhaber. Ein Bearer Token ist ein Inhaber-Token, das nicht an eine bestimmte Identität gebunden ist.

Token in der IT Sicherheit

In der IT Sicherheit werden Token für die Authentifizierung und Autorisierung von Benutzern und Systemen verwendet. Neben Hardware-Token wie z.B. Kryptokarten und Pin Generatoren können auch Daten als Token verwendet werden.

Die folgenden Token enthalten selbst sinnvolle Daten für den Empfänger bereit:

• JSON Web Token (JWT)
• X.509 Zertifikate
• Passwort Hashes

Des Weiteren gibt es Token, die als Stellvertreter dienen, z.B. für sensible Zugangsdaten, die auch Credentials genannt werden. Der Inhalt oder Wert eines Stellvertreter-Tokens hat selbst keine Bedeutung. Er ist nicht self-contained. Um ein Stellvertreter-Token zu schützen wird als Wert z.B. eine große Zufallszahl verwendet, die nicht leicht zu erraten ist.

Bearer Token Autorisierung für API Aufrufe

Im Folgenden wird eine API Autorisierung über das HTTP Protokoll mit einem Bearer Token beschrieben.

Als Parteien sind ein Keksmonster, eine Keksfabrik und eine Authentifizierungsstelle an der Kommunikation beteiligt. Um Kekse zu erhalten, möchte das Monster eine geschützte API der Keksfabrik aufrufen. Das folgende Bild zeigt diesen Aufbau.

Abbildung : Keksmonster, Keksfabrik und Authentifizierungsstelle für Bearer Token Autorisierung

Wir gehen davon aus, dass alle Aufrufe zusätzlich über das TLS Protokoll geschützt werden, damit das Token nicht auf dem Transportweg ausgespäht werden kann.

Die Geschichte beginnt damit, dass das Keksmonster nur noch einen Keks besitzt und dringend Nachschub benötigt. Den gibt es in der Keksfabrik. Aus diesem Grund macht das Keksmonster dort eine Anfrage, um neue Kekse zu bekommen.

Abbildung : Erste API Anfrage durch das Keksmonster

Die Anfrage sieht im HTTP Protokoll wie folgt aus:

GET /kekse HTTP/1.1

Die Keksfabrik liefert Kekse nur an autorisierte Keksmonster aus. Da die Anfrage des Monsters keine Autorisierung enthält, antwortet die Fabrik mit einem 401 Unauthorized Statuscode und lehnt die Lieferung ab.

Abbildung : Die Keksfabrik liefert keine Kekse ohne Bearer Token Autorisierung

Mit der Antwort liefert die Keksfabrik zwei wichtige Informationen an das Monster. Zum einen die Methode, mit der eine Autorisierung durchzuführen ist und zum anderen den Gültigkeitsbereich der Autorisierung. Die Antwort hat in etwa folgendes Aussehen:

HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm=“Keksfabrik“

Ok, stimmt… das Keksmonster erinnert sich, dass es zuvor auch nur autorisiert Kekse bekommen hat. Deswegen folgt jetzt ein kurzer Umweg über die Authentifizierungsstelle. Dort muss das Keksmonster seine Identität mit Benutzername und Passwort nachweisen.

Abbildung : POST Request zur Authentifizierung gegenüber der Authentifizierungsstelle

Die Anfrage des Monsters sieht wie folgt aus:

POST /ausgabe HTTP/1.1 { „user“:“Keksvernichter“, „password“:“U+1F36A“ }

Die Authentifizierungsstelle akzeptiert die Zugangsdaten. Der Keksvernichter ist dort als Keksmonster gut bekannt. Alle Voraussetzungen für die Ausstellung eines Tokens sind somit erfüllt.

Abbildung : Nach erfolgreicher Validierung stellt die Authentifizierungsstelle ein Bearer Token aus

Das Listing unten zeigt die Antwort der Fabrik mit dem Bearer Token im Body:

HTTP/1.1 200 Ok { „token“:“S0VLU0UhIExFQ0tFUiEK“ }

Super, jetzt kann das Keksmonster endlich neue Kekse anfragen! Das Keksmonster bereitet die nächste Nachricht vor um seine neue Keksration zu erhalten. Diese Anfrage gleicht der ersten Anfrage, aber dieses Mal ist das Bearer Token enthalten.

Abbildung : Anfrage nach Keksen mit Bearer Token im Authorization Header

Das Bearer Token wird als Authorization Header in die Anfrage eingebettet.

GET /kekse HTTP/1.1 Authorization: Bearer S0VLU0UhIExFQ0tFUiEK

Diesmal läuft das Prozedere etwas anders ab. Die Keksfabrik erkennt, dass die Anfrage ein Bearer Token für die Autorisierung enthält. Um dem Bearer Token zu vertrauen, muss dieses überprüft bzw. validiert werden.

Die Keksfabrik benötigt die Hilfe der Authentifizierungsstelle, da das Token über keinen kryptographischen Schutz verfügt. Tokens, die über einen kryptographischen Schutz z.B. eine Signatur verfügen, können von den Empfängern direkt überprüft werden. Bei APIs wird der Einfachheit halber oft ein Token ohne Kryptographie verwendet.

Um das Token zu validieren wird es an die Authentifizierungsstelle geschickt.

Abbildung : Die Keksfabrik sendet das Token zur Validierung an die Authentifizierungsstelle

Die Anfrage zur Validierung des Tokens sieht wie folgt aus:

POST /validate HTTP/1.1 { „token“:“S0VLU0UhIExFQ0tFUiEK“ }

Das Token ist bei der Authentifizierungsstelle bekannt, da dieses vor wenigen Sekunden von ihr selbst für das Monster ausgestellt wurde. Das Token ist auch nicht abgelaufen, da kein Timeout überschritten wurde. Die Authentifizierungsstelle antwortet wie erwartet, dass das Token gültig ist.

Abbildung : Das Bearer Token ist gültig

Die Authentifizierungsstelle antwortet der Keksfabrik mit einer Erfolgsmeldung:

HTTP/1.1 200 Ok

Die Keksfabrik hat die Verbindung zum Keksmonster aufrechterhalten und sendet nun die Antwort – Kekse!

Abbildung : Das Keksmonster ist am Ziel. Die Kekse werden über die Leitung geschickt

Die Antwort der Keksfabrik:

HTTP/1.1 200 Ok [„Keks“, „Keks“, „Keks“]

Das Keksmonster hat erfolgreich einen autorisierten Aufruf mit Hilfe eines Bearer Tokens durchgeführt.

Zusammenfassung und Ausblick

Im Beispiel wurden alle Schritte für eine Autorisierung mit Bearer Token aufgezeigt. Wird eine geschützte API ohne Token aufgerufen, bekommt der Aufrufer einen Hinweis, dass eine Autorisierung erfolgen muss. Um ein Token zu erhalten muss die Identität des Aufrufers überprüft werden. Ist das erfolgreich geschehen, so wird ein Bearer Token ausgestellt. Dies kann für den API Aufruf verwendet werden. Ist das Token nicht self-contained, so muss die API das Token über einen Dritten validieren. Bei erfolgreicher Validierung des Tokens wird die Anfrage des Aufrufers durchgeführt.

Der Round-Trip zur Authentifizierungsstelle kann eingespart werden, wenn ein self-contained Token verwendet wird. Beispielsweise ein JSON Web Token mit einer digitalen Signatur. Der Preis für den eingesparten Aufruf ist eine höhere Komplexität durch die Kryptographie. Bei beiden Varianten handelt es sich um Bearer Token, mit denen sich der Inhaber ausweisen kann.

Bearer Token werden für OAuth2 und API Keys verwendet. Hier findest du einen weiteren Artikel mit einer Einführung in OAuth2 und einen Einblick in den Authorization Code Ablauf.