Kommerzielle Plattformen ermöglichen es verschiedenen Akteuren, Geschäfte abzuschließen, operative Prozesse anzustoßen und Business-Services zwischen Teilnehmern zu vermitteln. Doch beim Aufsetzen solcher Plattformen ist Vorsicht geboten: Nicht nur vor dem Hintergrund der DSGVO müssen Sicherheit und Datensparsamkeit als zentrale Aspekte in der Plattformarchitektur berücksichtigt werden. Welche Technologien eignen sich dabei, um Anmeldedaten und Profilinformationen zu föderalisieren, ohne dabei sicherheitskritische Nutzerprofile zu sammeln?

Schauen wir uns hierfür als erstes OAuth an. In der modernen Welt der sozialen Medien nutzt jeder von uns jeden Tag Dutzende von Anwendungen und Websites. Um nicht ständig ein neues Profil bei jedem einzelnen Anbieter erstellen zu müssen, wird seit 2012 auf Initiative von Facebook und Twitter das Autorisierungsprotokoll OAuth entwickelt. Es beschreibt, wie vorher gegenseitig miteinander bekannt gemachte Dienste im Namen ihrer Nutzer:innen sicher auf ihre Ressourcen zugreifen können, ohne die konkreten Anmeldeinformationen miteinander zu teilen. Auf diese Weise lässt sich ein bereits erstelltes Konto (zum Beispiel bei Facebook oder Google) zum Login bei anderen Diensten verwenden, ohne Passwort oder E-Mail-Adresse preiszugeben. Grob umrissen funktioniert OAuth wie folgt.

Nehmen wir an, Melanie möchte sich bei Aliexpress registrieren und wählt als eine der angebotenen Optionen „Sign up with Google“:

1. Aliexpress erstellt eine URL zu Googles Anmeldedienst, die die gewünschten Profil-Bereiche (Scopes) beinhaltet, die es von Melanies Profil benötigt, und leitet Melanies Browser auf diese URL weiter.
2. Google erkennt, dass die Anfrage von Aliexpress stammt, und weist Melanie darauf hin, über welche Informationen und Google-Dienste Aliexpress im Falle ihrer Zustimmung verfügen können wird.
3. Melanie erteilt Google die Erlaubnis, Aliexpress die Daten aus den gewünschten Scopes freizugeben.
4. Die Google-API sendet einen einmaligen Grant-Token an Aliexpress, den der Dienst mit einem zwischen ihm und Google ausgehandelten Geheimnis beantwortet, um Aliexpress eindeutig identifizieren zu können.
5. Google antwortet mit einem Access-Token, der Melanies Authentifizierung und Freigaben repräsentiert.
6. Aliexpress übermittelt bei jeder Anfrage an eine der autorisierten Google-API Melanies Access-Token.
7. Die Google-API prüfen die Gültigkeit des Tokens und liefern die angeforderten Daten an Aliexpress.

Das OAuth-Protokoll hat den Weg für föderalisierte Anmelde- und Autorisierungsprotokolle geebnet. Es leidet aber unter der starken Korrelierbarkeit von Metadaten: Google lernt sehr viel über das Informationsverhältnis zwischen Aliexpress und Melanie. Weiterhin ist das Verfahren stark von der Verfügbarkeit und dem guten Willen seitens Google abhängig und erfordert, dass Clients Token und dienstspezifische Geheimnisse für sich behalten können und sich vor der Anwendung des Verfahrens aktiv miteinander bekannt machen.

Mit JSON Web Token (JWT) liegt seit einigen Jahren eine JSON-basierte Spezifikation für Security-Token vor, deren Integrität mithilfe kryptographischer Signaturen sichergestellt wird. JWT enthalten alle für einen Anwendungsfall relevanten Authentifizierungs- und Autorisierungsinformationen einer Entität. Dadurch entfällt die Notwendigkeit, Datenbanken zur Feststellung von Berechtigungen abzufragen oder Sitzungsdaten auf dem Server zu speichern („Stateless Session“).

Das hat dazu geführt, dass JSON Web Token besonders zur Authentifizierung in verteilten Systemlandschaften beliebt geworden sind. Nach einer erfolgreichen Identifizierung stellt ein Authentifizierungsserver dem Nutzer einen JWT mit Autorisierungsinformationen und gegebenenfalls persönlichen Merkmalen aus und signiert ihn mit einem Schlüsselpaar, dessen öffentlichen Schlüssel er anderen Applikationsservern bekannt machen kann. Die Applikationsserver können, sobald jemand ihnen einen JWT als Authentifizierungsmerkmal präsentiert, durch Überprüfung der Signatur sicherstellen, dass die Information aus dem Token tatsächlich von einem Authentifizierungsserver stammt, dem sie vertrauen.

JWT eignen sich hervorragend zur Nutzerauthentifizierung in Microservice-Umgebungen. Anders als monolithische Backend-Architekturen können sie sich keinen Session-State teilen. Um eine Anfrage authentifizieren und seine Autorisierungen belegen zu können, benötigen sie lediglich Kenntnis über ein öffentlich zugängliches Zertifikat, gegen das sie die Signatur des JWT verifizieren. Anmeldedienste können das auch dafür nutzen, Autorisierungen für Drittsysteme bereitzustellen.

Da JWT an sich selbst genügende Authentifizierungsmerkmale darstellen, hängt ihre Sicherheit vorrangig davon ab, dass ihre Nutzer sie geheim halten und sie nicht auf dem Transportweg abgefangen werden. Daher werden sie üblicherweise nur mit sehr kurzfristigen Ablaufdaten versehen und müssen von ihren Nutzern mithilfe von ausschließlich für diesen Anwendungsfall dienenden Refresh-Token regelmäßig erneuert werden.

Ebenfalls interessant: Hello Token, bye-bye Password! GitHub soll 2021 sicherer werden

Während OAuth und JWT den aktuellen Standard für Platform-Security darstellen, leiden sie immer noch darunter, dass sie auf einem zentralen Authentifizierungsverfahren und föderalisiertem Vertrauen beruhen. Perspektivisch werden sie daher durch sogenannte Self-Sovereign-Identities (SSI) abgelöst. Allgemein bedeutet SSI, dass Personen ihre digitale Identität vollkommen selbständig verwalten (etwa in Form einer Wallet auf einem mobilen Endgerät) und nicht mehr von einem zentralen Identitätsdienstleister abhängig sind. Die Authentifizierung erfolgt statt durch den Austausch von E-Mail/Passwort-Kombinationen durch den Nachweis über die Kontrolle eines sogenannten Decentralized Identifiers (DID) mithilfe digitaler Signaturen. Je nach Anwendungsfall kann ein Nutzer mehrere DID für verschiedene Aspekte seiner digitalen Identität verwenden. DID repräsentieren im Wesentlichen eine Sammlung von Schlüsseln, die auf öffentlich zugänglichen Systemen auflösbar sind. Typischerweise werden sie nicht in einem Informationssilo wie einem föderierten Google-Authentifizierungsdienst vorgehalten, sondern mithilfe von dezentral ausgelegten, vertrauenslosen Systemen wie Blockchains zur aktuell gültigen Fassung aufgelöst. Autorisierungen werden mithilfe sogenannter Verifiable Credentials über DID ausgestellt. Die können ihrerseits als JWT präsentiert werden. Ihre Legitimität lässt sich mithilfe der in einem DID-Dokument hinterlegten Public Keys von Aussteller und Authentifizierungssubjekt durch ein Drittsystem verifizieren.

Die Suche nach Wegen und Technologien, um Nutzerinformationen auf Plattformen sicher und einfach auszutauschen, ist noch lange nicht abgeschlossen. Während gängige föderalisierte Authentifizierungs- und Rechtemanagementverfahren sowohl problematische Konsequenzen für Sicherheit, Korrelierbarkeit und Datenschutz mit sich bringen, konfrontieren selbstsouverän kontrollierte Identitäten ihre Nutzer:innen mit der Verantwortung, ihre Geheimnisse selbst bewahren zu müssen. Dezentrale Vertrauensdienste aus der Welt der Distributed-Ledger-Technologien lösen zwar die Verankerung und Sicherstellung von öffentlichen Identitätsmerkmalen, werfen aber neue Fragen zur Nachverfolgbarkeit und Bedienbarkeit auf und sind nur mühevoll zur Interoperabilität untereinander zu bewegen. Das Ziel, sich mit einem selbstsouverän ausgestellten und staatlich beglaubigten Personalausweis an beliebigen Systemen anzumelden, ohne dabei die gesamte Anmeldehistorie zu veröffentlichen, liegt noch vor uns. Spätestens dann ließen sich aber die unheiligen Profilierungs- und Anmeldeserver föderalisierter Datenkraken endgültig abschalten.