Token

Im Bereich der Authentifizierung und Autorisierung ist ein Token (aus dem Englischen für Merkmal) ein digitales Objekt. Ein verschlüsselter, maschinell generierter Code und dadurch grundsätzlich sicherer als Passwörter. Als in sich geschlossene Einheit, enthält ein Token alle Informationen zur Identität des Kontos, das die Anfrage stellt und zu welcher Art von Zugriff es autorisiert ist.

Jedes im Autorisierungsverfahren eingesetzte Token gilt dabei ausschließlich für eine spezielle Sitzung eines Benutzers. Geschützt durch einen Algorithmus, können manipulierte Token vom Server identifiziert und abgelehnt werden. Grundsätzlich ist ein Token mit einem Verfallsdatum versehen. Umso geringer die maximale Lebensdauer eines Tokens ist, als umso sicherer ist dieser Token auch grundsätzlich anzusehen. Längere Lebensdauer ist besser für die Nutzerfahrung und für einen ökonomischen Betrieb der Serverinfrastruktur. Deshalb muss immer ein guter Kompromiss zwischen zu kurzer und zu langer Lebensdauer gefunden werden.

Welches Token gibt es?

Nachfolgend einige Token Arten die unter OpenID Connect (OIDC) das als Standard Authentifizierungsprotokoll gilt und auf OAuth2.0 aufbaut, verwendet werden:

ID-Token

Ein ID-Token ist ein JSON-Webtoken (JWT) und entspricht der OIDC-Spezifikation. Es enthält Daten darüber, wie und wann sich ein Benutzer authentifiziert hat. Es kann aber auch Daten über den Nutzer selbst beinhalten, wie Name, E-Mail oder Telefonnummer. Und da ein ID-Token transparent ist, kann es von einer Anwendung geprüft und verwendet werden. Darüber hinaus können die Identitätsinformationen für die Authentifizierung eines Benutzers verwenden werden. Gültig sind ID-Token üblicherweise bis zu 1 Stunde (3.600 Sekunden) und nach Ablauf muss der Client ein neues ID-Token anfordern. Ein ID-Token ist durch den ausstellenden Identity Provider (IdP) signiert, wodurch der Client prüfen kann, ob der Token manipuliert wurde und wer der Aussteller war. Dieses Token stellt der IdP an den Client (App, Webanwendung usw.) des Benutzers aus.

Access-Token (Zugriffs-Token)

Ein Access-Token ist ein intransparentes Token und entspricht dem OAuth2.0 Framework. Es enthält Authorisierungsinformationen (User-Berechtigungen und Ablauffristen), jedoch üblicherweise keine Identitätsdaten und ermöglicht den Zugriff auf spezielle Nutzerressourcen. In den meisten Fällen ist dieser ein JSON-Webtoken (JWT) oder auch anbieterspezifische Formate. Nicht nur das Grundformat kann anbieterspezifisch sein- auch im Falle von JWT können die darin enthaltenen Informationen teilweise stark voneinander abweichen. Mit diesen Tokens können Clients „im Auftrag von Benutzern“ agieren. Wenn ein Client mit einem Token bspw. auf eine API zugreift, erfährt der dahinter liegende Server welcher Benutzer das war und dass dieser Client für diese Aktion vertrauenswürdig ist. Die Prüfung des Access-Tokens kann grundsätzlich von jedem Teilnehmer (Client, wie Server) durchgeführt werden. Bei einer Prüfung wird sich in den meisten Fällen (wie beim ID-Token) auf die Signatur des IdPs verlassen. Es kann aber auch notwendig sein jedes Mal einen dedizierten API-Endpunkt des IdPs aufzurufen, um diesen Token zu verifizieren. Wir bei Engity verwenden primär JWT hierfür.

Die Lebensdauer von Access-Tokens beträgt heutzutage üblicherweise zwischen 15 Minuten und 1 Tag.

Refresh-Token

Meldet sich der Benutzer an einer geschützten Ressource an, erhält er neben dem Access-Token, auch ein Refresh-Token. Läuft dann die Gültigkeit eines Access-Token ab, kann mit dem Refesh-Token ein neues, gültiges Access-Token angefordert werden. Ein Refresh-Token kann i.d.R. nur ein Mal verwendet werden und zusammen mit dem neuen Access-Token erhält man auch jedes Mal einen neuen Refresh-Token. Ein Refresh-Token ist ebenfalls ein OAuth2.0 Konstrukt und hat eine sehr lange bis unbegrenzte Gültigkeit. Es kann aber aufgrund von Session-Timeouts, aufgrund einer Änderung der Anmeldinformationen oder anderer Events jederzeit widerrufen werden.

Die Lebensdauer eines Refresh-Tokens beträgt heutzutage üblicherweise zwischen 1 Stunde und 1 Jahr. Das ist abhängig davon, wie schützenswert die Information ist, die mit diesem Token gesichert wird.

Session-Token

Ein Session-Token, in anderen Kontexten auch Session-Cookie oder Session-ID ist kein OIDC- oder OAuth2.0 Standard. Es enthält eine verschlüsselte, eindeutige Zeichenfolge und wird als Identifikationsmerkmal verwendet. Das Session-Token wird hierbei lokal beim User im Browser Storage gespeichert und wird bei jeder Anfrage an den Server übermittelt, geprüft und bei Übereinstimmung wird die Anfrage bearbeitet. Ein Session-Token hilft auch dabei die Session so lange wie möglich aktiv zu halten. Ist zum Beispiel der Access- und Refresh-Token abgelaufen, aber es gibt noch einen gültigen Session-Token, erfolgt ein sogenannter Silent-Login mit Hilfe des Session-Tokens. Erst wenn der User sich aktiv von der Anwendung abmeldet, wird der Session-Token auf der Client- und/oder auf der Server-Seite zerstört und der User müsste sich neu anmelden.

Authorization-Code

Hat sich ein Benutzer erfolgreich authentifiziert, schickt der OpenID Provider (OP) einen Authorization-Code an den Browser des Nutzers. Dieser Code wird im nächsten Schritt an die Anwendung die Relying Party geschickt und der Browser erhält im Gegenzug einen Access-Token, Refresh-Token und ID-Token.

Die Lebensdauer eines Authorization-Codes überschreitet üblicherweise 5 Minuten nicht.