Wie können Entwickler moderne Webanwendungen effektiv schützen?
Cookies vs. Tokens - Authentifizierung richtig gedacht
In einer Welt voller Cyberbedrohungen ist Datensicherheit kein Nice-to-have mehr – sie ist Pflicht. Doch wie schützt man moderne Webanwendungen effektiv? Unser Entwickler Alexander hat das Thema Websecurity aufbereitet und auf der diesjährigen OVConference in einem Vortrag vorgestellt. Die wichtigsten Erkenntnisse und Empfehlungen haben wir in diesem Fachartikel zusammengefasst – darauf kommt es an:
Was sollte geschützt werden?
Datensicherheit ist ein zentrales Thema in der heutigen digitalen Welt. Dabei geht es nicht nur um technische Maßnahmen, sondern auch um ein grundlegendes Verständnis davon, was genau geschützt werden muss. Im Kern lassen sich drei Hauptaspekte der Datensicherheit unterscheiden:
- Vertraulichkeit – Schutz der Privatsphäre: Wer darf auf Daten zugreifen?
- Integrität – Schutz vor Manipulation: Wurden die Daten verändert?
- Authentizität – Herkunftssicherheit: Von wem stammen die Informationen?
Gerade der Aspekt der Authentizität spielt eine entscheidende Rolle bei der Anmeldung in Webanwendungen, auf den wir uns im Folgenden konzentrieren wollen.
COOKIES VS. TOKENS
Der Klassiker: Cookie-basierte Authentifizierung
Traditionelle Webanwendungen, wie sie z. B. in PHP oder .NET entwickelt werden, setzen meist auf Cookie-basierte Authentifizierung. Dabei läuft der Prozess in etwa so ab:
- Ein Benutzer meldet sich über ein Formular im Browser an.
- Der Server prüft die Anmeldedaten.
- Bei Erfolg sendet der Server ein Cookie zurück, das eine aktive Session repräsentiert.
- Bei allen weiteren Anfragen wird dieses Cookie automatisch vom Browser mitgesendet.
So weiß der Server, ob ein Benutzer authentifiziert ist. Ist das Cookie abgelaufen oder fehlt es, erhält der Browser eine 302-Weiterleitung – in der Regel zur Login-Seite.
Diese Methode funktioniert sehr gut, sofern sich alle Teile der Anwendung auf derselben Domain befinden.
Die moderne Lösung für Single-Page-Apps: Token-basierte Authentifizierung
Mit dem Aufstieg von Frameworks wie Angular, React oder Vue haben sich sogenannte Single-Page Applications (SPA) etabliert. Diese laden den Anwendungscode einmalig in den Browser und kommunizieren dann über APIs.
Cookies stoßen hier schnell an ihre Grenzen – insbesondere dann, wenn die APIs auf anderen Domains liegen. Denn Cookies sind nicht herkunftsübergreifend. Deshalb verwenden moderne SPAs Token-basierte Authentifizierung:
- Der Benutzer meldet sich an.
- Der Authentifizierungsserver gibt ein Token aus.
- Die Anwendung speichert das Token temporär.
- Bei API-Aufrufen wird das Token per HTTP-Header mitgesendet.
Der Vorteil: Token lassen sich auch mit APIs auf anderen Domains verwenden. Aber wo soll man diese Token sicher speichern?
Speichern von Tokens: Warum der lokale Speicher problematisch ist.
Viele Entwickler greifen bei der Speicherung von Tokens auf den Local Storage zurück, da er eine einfache Möglichkeit bietet, Sitzungen persistent zu halten. Doch diese Methode birgt erhebliche Sicherheitsrisiken: Local Storage ist für jedes JavaScript auf der Seite zugänglich, was bedeutet, dass Angreifer bei einem Cross-Site-Scripting-Angriff (XSS) problemlos auf die gespeicherten Tokens zugreifen können. Zudem wird der Local Storage nicht automatisch mit jeder Anfrage an den Server gesendet, wodurch eine zentrale Session-Kontrolle – wie sie etwa bei Cookies möglich ist – fehlt. Ein weiteres Problem ergibt sich, wenn mehrere Anwendungen auf derselben Domain laufen. Sie teilen sich denselben Speicherbereich, was zu unerwünschten Wechselwirkungen führen kann.
Besser: Temporärer Speicher und "Silent Refresh"
Statt Tokens im Local Storage zu speichern, empfiehlt es sich, sie im App-internen Speicher (Memory) zu halten. Doch was passiert, wenn die Seite neu geladen wird und der Memory-Inhalt verloren geht? Die Lösung liegt in einem sicheren Session-Cookie, das einen „Check-Session“-Mechanismus unterstützt. Dieses Cookie enthält keine sensiblen Daten, sondern dient lediglich dazu, den Status der Benutzersitzung zu prüfen. Beim Neuladen der Seite kann die Anwendung mithilfe eines sogenannten Silent Refresh – also einer stillen, automatisierten Anfrage ohne Nutzerinteraktion – beim Authentifizierungsserver ein neues Token anfordern, solange das Session-Cookie vorhanden ist. So bleibt der Nutzer sicher angemeldet, ohne erneut eingreifen zu müssen – eine benutzerfreundliche und zugleich sichere Lösung.
BEST PRACTICES
Authentifizierung sicher und modern umsetzen
Die Spezifikation von OAuth 2.0 (aus 2012) war ursprünglich nicht für SPAs gedacht. Dennoch gibt es heute erprobte Best Practices, mit denen sich sichere SPAs umsetzen lassen – z. B. Proof Key for Code Exchange (PKCE):
- Die Anwendung generiert einen Code Verifier mit hoher Entropie.
- Daraus wird per Hashing eine Code Challenge gebildet.
- Diese wird beim Login mitgesendet.
- Der Auth-Server gibt einen Code zurück.
- Die Anwendung sendet diesen Code zusammen mit dem Verifier zurück.
- Nur wenn Challenge und Verifier übereinstimmen, wird ein Token ausgegeben.
Diese Methode schützt vor gängigen Angriffsvektoren wie dem Token-Leak im Referrer-Header oder Man-in-the-Middle-Attacken.
Zudem existieren mittlerweile ausgereifte SDKs, die den gesamten Ablauf vereinfachen.
Angular & Authentifizierung: Ein Überblick für Entwickler
Angular bietet mit RxJS ein starkes Toolset, um reaktiv auf Authentifizierungsereignisse zu reagieren – selbst bei SDKs, die ursprünglich nicht reaktiv gebaut wurden.
Eine einfache Checkliste für Angular-Entwickler:
- Authentifizierungsergebnisse verwalten: Login, Logout, Token-Refresh
- Tokens bei API-Requests mitsenden: via HTTP-Interceptor
- Routen schützen: mit Guards und Rollenprüfungen
Diese Prinzipien bilden die Grundlage für eine sichere und benutzerfreundliche Authentifizierungsarchitektur in modernen Angular-Anwendungen.
FAZIT
Die Wahl der richtigen Authentifizierungsstrategie hängt stark von der Architektur der Anwendung ab. Wenn eine klassische Server-Rendering-App gebaut wird, sind Cookies nach wie vor eine einfache Lösung. Wird hingegen eine moderne SPA entwickelt, sollte auf Token-basierte Authentifizierung mit PKCE und „silent refresh“ via Cookie gesetzt werden. So lassen sich Sicherheit und Benutzerfreundlichkeit optimal vereinen.
Haben Sie noch Fragen?
Sie stehen vor der Entscheidung, welche Strategie zu Ihrer Anwendung passt? Oder möchten Ihre bestehende Architektur sicherer gestalten? Wir beraten Sie gerne in allen Fragen rund um Websecurity und unterstützen bei der Konzeption und Umsetzung Ihrer Authentifizierungsstrategie. Sprechen Sie uns einfach an – gemeinsam finden wir die passende Lösung.
WEITERE INTERESSANTE BLOGARTIKEL
Automatisiertes
Testen
Bessere Softwarequalität und mehr Effizienz im Projekt durch automatisiertes Testen mithilfe von Cypress, Cucumber & XRay. Mehr dazu in diesem Beitrag.
Synchr. Anwendungen in der Cloud
Weltweiter Zugriff, geringe Latenzen, hohe Verfügbarkeit – mehr zu der Umsetzung synchronisierter Anwendungen in der Cloud in unserem Artikel.
OVFokus: WEBPORTAL-
entwicklung
6 Beiträge rund um das Thema Webportale – von IAM über Usability und Hosting bis zu Barrierefreiheit. Hier geht es zur Übersicht.
VergLeich: INUBIT BPM UND CAMUNDA BPM
Worin unterscheiden sich die beiden BPM Engines? Wann nutze ich welche? Antworten darauf in unserem Artikel aus der Reihe OVFacts.