Token Based Authentication
Zugriff über zeitlich begrenzte Zugangsnachweise
Die Idee und ihr Nutzen
Mara arbeitet als Sachbearbeiterin bei einer Versicherung und will in ihrer Anwendung Schadenfall 4711 öffnen. Morgens meldet sie sich einmal beim Identitätsdienst an, einem eigenen Programm der Versicherung, das Benutzernamen und Passwörter prüft. Der Identitätsdienst gibt Maras Anwendung danach einen zeitlich begrenzten Zugangsnachweis, ein sogenanntes Token. Das Token ist eine lange Zeichenfolge, die zum Beispiel nur bis 9 Uhr gilt. Bei jeder weiteren Anfrage schickt die Anwendung dieses Token statt des Passworts mit. So läuft Maras Passwort nicht durch alle Dienste, die Mara im Laufe des Tages nutzt. Der Schadendienst, das Programm mit den Schadenakten, prüft anhand des Tokens, wer die Anfrage stellt, und prüft zusätzlich, ob Mara die Akte zu Schadenfall 4711 bearbeiten darf. Dieses Vorgehen heißt tokenbasierte Authentifizierung, englisch Token Based Authentication. Authentifizierung heißt der Nachweis, wer eine Anfrage stellt.
Wie funktioniert es?
Mara meldet sich um 8 Uhr mit ihrem Passwort und einem zusätzlichen Code beim Identitätsdienst an. Den Code liefert zum Beispiel eine App auf ihrem Telefon. Der Identitätsdienst prüft beides und gibt Maras Anwendung ein Token, das bis 9 Uhr gilt und für den Schadendienst bestimmt ist. Eine Stunde ist kurz genug, dass ein gestohlenes Token bald nicht mehr nutzbar ist, und lang genug, dass die Anwendung nicht ständig ein neues Token beim Identitätsdienst holen muss. Das Passwort verlässt Maras Anwendung danach nicht mehr. Um 8:20 Uhr öffnet Mara Fall 4711, und ihre Anwendung schickt die Anfrage „Fall 4711 öffnen“ zusammen mit dem Token an den Schadendienst. Der Schadendienst prüft zuerst das Token: Es ist echt, noch nicht abgelaufen und für den Schadendienst ausgestellt. Danach fragt der Schadendienst die Fallberechtigung, ob Mara für Fall 4711 zuständig ist. In der Fallberechtigung ist festgehalten, welche Fälle welcher Sachbearbeiterin zugewiesen sind. Die Fallberechtigung antwortet „ja, zugewiesen“, und der Schadendienst schickt Mara die Akte.
Nicht nur der Schadendienst prüft das Token selbst. Will Mara danach in der Vertragsauskunft, dem Programm mit den Vertragsdaten, ihren Vertrag nachsehen, holt ihre Anwendung beim Identitätsdienst ein Token, das für die Vertragsauskunft ausgestellt ist. Die Vertragsauskunft prüft dieses Token, bevor sie die Anfrage bearbeitet. Es gibt zwei verbreitete Arten von Tokens. Die eine Art enthält Angaben wie Name, Ablaufzeit und vorgesehenen Empfänger und ist vom Identitätsdienst digital unterschrieben. Die digitale Unterschrift belegt, dass das Token vom Identitätsdienst stammt und seitdem nicht verändert wurde. Ein Dienst kann diese Unterschrift selbst prüfen, ohne beim Identitätsdienst nachzufragen. Die andere Art ist nur eine zufällige Zeichenfolge. Bei einer solchen Zeichenfolge muss der Dienst beim Identitätsdienst nachfragen, ob sie gültig ist und zu wem sie gehört. Ein Token belegt nur, wer anfragt. Ob Mara einen bestimmten Schadenfall sehen oder ändern darf, entscheidet der Schadendienst mit seinen eigenen Regeln, hier mit der Fallberechtigung.
Hätte Maras Anwendung ein abgelaufenes Token geschickt oder ein Token, das für einen anderen Dienst ausgestellt wurde, hätte der Schadendienst die Anfrage abgelehnt. Ebenso lehnt der Schadendienst eine Anfrage mit gültigem Token ab, wenn Mara für den Fall nicht zuständig ist. Würde jemand Maras Token um 8:30 Uhr stehlen, könnte er das Token bis 9 Uhr missbrauchen. Das gilt, sofern der Identitätsdienst das Token nicht vorher ausdrücklich für ungültig erklärt und der Schadendienst davon erfährt, weil er beim Identitätsdienst nachfragt.
Tokenbasierte Authentifizierung: erst das Token, dann die Fallberechtigung
Wann ist es sinnvoll und wann nicht?
Tokenbasierte Authentifizierung lohnt sich
- Mehrere Anwendungen und Dienste nutzen eine gemeinsame, zentrale Anmeldung. Mara nutzt im Laufe des Tages den Schadendienst, die Vertragsauskunft und weitere Dienste. Müsste ihre Anwendung jedem dieser Dienste bei jeder Anfrage das Passwort schicken, könnte jeder Dienst das Passwort versehentlich in eine Protokolldatei schreiben oder bei einem Angriff preisgeben. Ein bekannt gewordenes Passwort gilt, bis Mara es ändert. Ein gestohlenes Token ist dagegen nur bis 9 Uhr nutzbar.
- Ein Nachweis soll nur für bestimmte Dienste gelten. Stünde im Token kein vorgesehener Empfänger, könnte die Vertragsauskunft mit dem Token, das Maras Anwendung ihr geschickt hat, Anfragen an den Schadendienst stellen, als käme die Anfrage von Mara. So aber prüft der Schadendienst den vorgesehenen Empfänger und nimmt kein Token an, das für einen anderen Dienst ausgestellt wurde.
- Viele Dienste sollen Anfragen prüfen, ohne bei jeder Anfrage den Identitätsdienst zu fragen. Ohne Tokens mit digitaler Unterschrift fragen Schadendienst und Vertragsauskunft bei jeder Anfrage beim Identitätsdienst nach, und jede Anfrage wartet auf den Identitätsdienst. Schadendienst und Vertragsauskunft prüfen ein Token mit digitaler Unterschrift dagegen selbst. Der Identitätsdienst wird dann nicht mit jeder Anfrage belastet.
Tokenbasierte Authentifizierung ist nicht das Richtige
- Es gibt nur eine einzelne Anwendung ohne weitere Dienste. Maras Passwort erreicht dann ohnehin nur den Server dieser Anwendung, und es gibt keine weiteren Dienste, von denen ein Token das Passwort fernhalten müsste. Dann richtet das Team der Anwendung eine Sitzung ein: Der Server der Anwendung prüft Maras Passwort bei der Anmeldung selbst, merkt sich danach, dass Mara angemeldet ist, und erkennt Mara an einer zufälligen Sitzungskennung, die ihr Browser bei jeder Anfrage mitschickt. Löscht der Server die Sitzung, ist der Zugang sofort gesperrt. Weil nur dieser eine Server die Anfragen prüft, entfallen der Identitätsdienst als zusätzliches Programm, das betrieben werden muss, und die Prüfung digitaler Unterschriften.
- Es soll geregelt werden, wer auf welchen Datensatz zugreifen darf. Das klärt ein Token nicht. Dann legt das Team des Schadendienstes zusätzlich Zugriffsregeln fest. Für Mara ist das die Fallberechtigung, die festhält, welche Fälle ihr zugewiesen sind. Gelten Rechte für alle Mitarbeitenden einer Rolle wie „Sachbearbeitung“ gleich, eignet sich Role Based Access Control, also Rechte, die an Rollen hängen. Der Schadendienst gibt eine Akte dann nur heraus, wenn diese Regeln es erlauben.
- Ein entzogener Zugang muss in jedem Dienst sofort gesperrt sein. Dann genügen Tokens nicht, die die Dienste nur anhand der Unterschrift im Token prüfen. Der Identitätsdienst gibt stattdessen Tokens aus, die nur eine zufällige Zeichenfolge sind, und Schadendienst und Vertragsauskunft fragen bei jeder Anfrage beim Identitätsdienst nach, ob das Token noch gültig ist. Ein entzogener Zugang ist so ab der nächsten Anfrage gesperrt und gilt nicht bis zum Ablauf des Tokens weiter.
Nachteile und typische Fehler
Der Identitätsdienst ist ein zusätzliches Programm, von dem jede Anmeldung abhängt. Fällt der Identitätsdienst aus, kann sich niemand anmelden, und keine Anwendung erhält ein neues Token. Tokens, die ein Dienst selbst anhand der Unterschrift prüft, lassen sich vor ihrem Ablauf nur mit zusätzlichem Aufwand widerrufen, also vorzeitig für ungültig erklären. Solche Tokens sollten deshalb nur kurz gültig sein, und die Anwendung muss dann regelmäßig neue Tokens beschaffen. Fragt ein Dienst dagegen bei jeder Anfrage beim Identitätsdienst nach, erfährt der Dienst von einem Widerruf sofort, aber jede Anfrage dauert länger und belastet den Identitätsdienst.
Typische Fehler und woran man sie erkennt:
- Gestohlenes Token: Tokens werden nicht so sorgfältig geschützt wie Passwörter. Maras Anwendung schreibt das Token zum Beispiel in eine Protokolldatei, die viele Mitarbeitende lesen können. Jemand kopiert das Token aus der Protokolldatei und schickt damit bis 9 Uhr eigene Anfragen an den Schadendienst. Erkennbar ist das an Anfragen mit demselben Token von zwei verschiedenen Rechnern zur gleichen Zeit.
- Unvollständige Prüfung: Jeder Dienst muss Unterschrift, Aussteller, vorgesehenen Empfänger und Ablaufzeit prüfen. Vergisst ein Dienst eine dieser Prüfungen, nimmt er womöglich abgelaufene Tokens oder Tokens für andere Dienste an. Erkennbar ist das an einem Test, bei dem der Dienst auf ein abgelaufenes oder für einen anderen Dienst ausgestelltes Token hin eine Akte zurückschickt.
- Token statt Berechtigung: Der Schadendienst liefert jede Akte an jeden, der ein gültiges Token vorlegt, und lässt die Prüfung der Zuständigkeit aus. Erkennbar ist das an Zugriffen auf Fälle, die der anfragenden Person nicht zugewiesen sind.
- Unbeachteter Widerruf: Der Identitätsdienst erklärt ein Token für ungültig, der Schadendienst prüft aber nur die Unterschrift und nimmt das Token bis zum Ablauf weiter an. Erkennbar ist das an Zugriffen mit einem Token, das bereits für ungültig erklärt wurde.
- Zu viele Angaben im Token: Ein Token enthält vertrauliche Angaben, die für die Prüfung nicht nötig sind. Die digitale Unterschrift schützt den Inhalt nur vor Veränderung. Lesbar ist der Inhalt oft für jeden, der das Token sieht. Erkennbar ist das an Adressen oder Personalnummern, die beim Auslesen eines Tokens ohne Schlüssel sichtbar sind.
Weiterführend
Verwandte Ansätze
- Single Sign On: Eine Sachbearbeiterin meldet sich einmal beim Identitätsdienst an und nutzt danach mehrere Anwendungen. Die Anmeldenachweise, die der Identitätsdienst dafür ausstellt, sind häufig Tokens.
- Attribute Based Access Control: entscheidet anhand von Eigenschaften der Person und des Datensatzes, ob ein Zugriff erlaubt ist, so wie die Prüfung, ob Fall 4711 Mara zugewiesen ist.
- Zero Trust: prüft jeden Zugriff einzeln, auch innerhalb des Firmennetzes. Tokens sind ein verbreitetes Mittel, mit dem jeder Dienst diese Prüfung selbst vornehmen kann.
Quellen
- Michael Jones, John Bradley, Nat Sakimura: RFC 7519, JSON Web Token (JWT): Standard für Tokens mit digitaler Unterschrift, der Angaben wie Aussteller, Empfänger und Ablaufzeit festlegt und verlangt, dass ein Empfänger ein Token ablehnt, das nicht für ihn bestimmt oder abgelaufen ist.
- Justin Richer: RFC 7662, OAuth 2.0 Token Introspection: Standard für Tokens, zu denen ein Dienst beim Identitätsdienst nachfragt, ob sie noch gültig sind und zu wem sie gehören.
- Yaron Sheffer, Dick Hardt, Michael Jones: RFC 8725, JSON Web Token Best Current Practices: Empfehlungen zur sicheren Prüfung solcher Tokens, unter anderem von Aussteller und Empfänger.