Know-how
Das Einloggen auf einer Webseite sollte sich einfach gestalten, wenn eine monolithische Architektur im Hintergrund ihren Dienst verrichtet. Was aber, wenn die Webseite von vielen Microservices befeuert wird? Woher wissen diese, dass die Nutzer die sind, die sie vorgeben zu sein? Hierfür können JSON Web Tokens eine sichere und performante Lösung sein.
Laut einer Bitkom-Studie verwenden 37 Prozent der Internetnutzer elf bis zwanzig Online-Dienste mit Login-Funktion. Für den Nutzer scheint der Vorgang des Einloggens im Frontend immer gleich zu sein. Benutzername oder E-Mail, Passwort, Enter ? fertig. Im Backend sieht die Angelegenheit etwas anders aus. Bei einer monolithischen Backend-Umgebung ist das Autorisierungssystem impliziert, und die Verifizierung des Users ist kein Problem. Hier kann die Anwendung das Tracking des Nutzers übernehmen.
Laut einer Studie des Softwareherstellers LeanIX geht der Trend in Unternehmen zur Nutzung von Microservices, und in solchen Umgebungen gestaltet sich die Autorisierung schwieriger. Hier müssen sich die Microservices entweder darauf verlassen, dass der Nutzer autorisiert ist, oder sie fragen bei jedem Aufruf den Autorisierungsservice, ob der Nutzer das Angebot überhaupt nutzen darf.
Letzteres hat ein stark verkettetes Microservice-Konstrukt zur Folge, da jede Microservice-Anfrage zu einer Anfrage an den Autorisierungsservice führt. Bei einem Ausfall des Services oder zeitlichen Verzögerungen sind die Auswirkungen aufgrund des schlechten Designs überall zu spüren.
Auth Calls innerhalb einer monolithischen Infrastruktur sind kein Problem (Abb. 1) … 
… im Microservice-Fall kommen allerdings Latenz und Ausfallrisiko dazu (Abb. 2).
Hier braucht es eine Lösung, die ein zuverlässiges Prüfen der Autorisierung erlaubt, ohne weitere Aufrufe zu benötigen.
JWT: Header, Payload & Signatur
An der Stelle können die JSON Web Tokens (JWT) den Unterschied ausmachen. Sie bestehen aus drei Teilen: Header, Payload und Signatur. Im Header enthält der JWT den Typ des Tokens sowie den genutzten Hashing-Algorithmus. Dieser liegt Base64-kodiert vor; genau wie der Payload. Letzterer enthält die Autorisierungsinformationen über den Nutzer und typischerweise seine Rechte sowie seine Namen. Darüber hinaus ist es sinnvoll, eine Gültigkeitsdauer im Payload mitzuschicken.
Die Signatur wird benötigt, um die Echtheit des Tokens zu verifizieren. Sie besteht aus kodiertem Header, Payload und Secret, das die Signatur des Autorisierungsservice ist, um so die Echtheit des Tokens überprüfen zu können.
oAuth2 „pur“: Tokens müssen gegen Resource Server verifiziert werden
OAuth2 mit JWT: Tokens lassen sich mit Public Key dezentral verifizieren (Abb. 4).
Da andere Microservices das Token anhand der Signatur verifizieren können, gibt es nach dem Login fast keine Calls an den Autorisierungsserver mehr. Das Signieren lässt sich mit einem „Private Public Key“-Verfahren durchführen. Dadurch müssen andere Microservices lediglich den Code zur Signaturprüfung enthalten und den Public Key kennen. Da das Token als Bearer Token im Autorisierungs-Header mitgesendet wird, können die Microservices ihn auswerten. Dank der Signatur gibt es keine Beschränkungen auf URLs. Das erlaubt auch Cross Site Authorization, was wiederum die Einmalanmeldung, den Single Sign-On (SSO), unterstützt und für den User von großem Interesse ist.
Community Nachrichten Deutsche News