In 10 Minuten weißt du …
Cookies, Sessions und Tokens gehören zu den wichtigsten Grundlagen moderner Webanwendungen.
In diesem Video lernst du, wie Browser, Backend, Authorization Server und APIs zusammenarbeiten und warum HTTP trotz seiner Zustandslosigkeit sichere Authentifizierung ermöglicht.
Warum dieses Thema wichtig ist
Fast jede moderne Webanwendung verwendet heute mindestens eines dieser Konzepte:
Wenn Du diese Standards kennst und je besser du sie verstehst, desto besser kannst Du moderne Authentifizierungsarchitekturen realisieren.
Das ist wichtig, weil Du somit wirksam IT Sicherheit in deine Anwendungen integrieren kannst um diese optimal zu schützen!
Rock the Prototype Essentials Video
Token Flow in 10 Minuten verstehen
Das lernst du
- 00:00 Cookie, Session oder Token?
- 00:16 Wo liegt die Authentifizierung – Browser, Backend oder Autorisation Server?
- 00:30 Client & Server: Session, Token, Request und Response
- 00:46 Secure by Design – Welche Komponente, erzeugt, speichert, prüft? – IT Architektur der Komponenten mit spezifischen ID-Funktionen
- 00:56 Speicher- und Sicherheitsmechanismen – Keychain, Secure Enclave, Trustes Execution Environment, HSM & Keystore
- 01:06 FaceID & Biometrie – SmartPhones & Native Apps
- 01:47 Warum HTTP stateless ist
- 02:19 Cookies sind nicht automatisch Tracking
- 02:40 Session Authentication und Session ID
- 03:16 Session Cookie, Session-ID und Session State
- 03:39 Authorization / Autorisierung
- 04:13 Cross-Site Request Forgery
- 05:07 HttpOnly, Secure und SameSite
- 05:48 Access Token, Refresh Token und ID Token
- 06:19 JWT und korrekte Token-Validierung
- 06:57 CSRF und XSS verstehen
- 07:51 DPoP – Proof of Possession
- 09:33 Native Apps, DPoP, mTLS & sender-constrained Tokens
Vertiefe Dein Wissen rund um moderne Authentifizierung
Dieses Video vermittelt die Grundlagen moderner Web-Authentifizierung und API-Autorisierung. Viele der behandelten Konzepte werden im Prototyping Wiki ausführlich vertieft und mit praxisnahen Beispielen ergänzt.
Wenn Du tiefer einsteigen möchtest, findest Du unter anderem weiterführende Artikel zu:
👉 Session
– HTTP Requests & Responses
– HTTP (Hypertext Transfer Protocol)
👉 REST APIs
👉 APIs (Application Programming Interfaces)
– Cookies
👉 Refresh Token
👉 JWT (JSON Web Token)
👉 JSON (JavaScript Object Notation)
– Backend for Frontend (BFF)
👉 OAuth 2.0
👉 OpenID Connect (OIDC)
👉 Zero Trust
– SPIFFE & SPIRE
– Demonstration of Proof-of-Possession (DPoP)
– Mutual TLS (mTLS)
👉 Digitale Identitäten (Identity)
👉 eIDAS 2.0 & die European Digital Identity Wallet
– OpenID Foundation Standards
👉 Kryptografie
– Kryptografische Hashfunktionen
👉 Public Key Infrastructure (PKI)
Alle diese Themen bauen aufeinander auf und helfen Dir dabei, moderne Authentifizierungs- und Autorisierungsarchitekturen zu verstehen, diese sicher zu implementieren und Webanwendungen, Apps und eigene Implementierungen in Software und Softwarearchitektur zu bewerten.
Cookie oder Token – Token Flow im Browser
Cookies, Sessions & Tokens – Die Grundlagen moderner Web-Authentifizierung
Moderne Webanwendungen sind weit mehr als einzelne, verlinkte Webseiten. Jede Website nutzt Browser, Backends, APIs, Authorization Server. Progressive Web-Apps und mobile Apps nutzen unterschiedliche Komponenten, Technologien und basieren auf etablierten Web-Standards. Aufgrund dieser Standards arbeiten Web-Technologien reibungslos zusammen und tauschen dabei Informationen wie auch Identitäts- und Sicherheitsinformationen aus.
Begriffe wie Cookie, Session, Access Token, Refresh Token, JWT, OAuth 2.0 oder OpenID Connect begegnen Software- und Web-Entwicklern, IT Architekten und Security Engineers heute nahezu täglich. Trotzdem werden diese Konzepte häufig vermischt oder sogar synonym verwendet – obwohl sie dabei völlig unterschiedliche Aufgaben erfüllen.
Dieses Video vermittelt die Grundlagen moderner Web-Authentifizierung anhand realer Client-Server-Kommunikation. Dabei betrachten wir die einzelnen Technologien im Zusammenspiel mit ihrem vollständigen Token Flow zwischen Browser, Backend, Authorization Server und API.
Warum Authentifizierung im Web & App so wichtig sind
Jede moderne Webanwendung muss die gleichen Funktionen beherrschen:
- Wie erkennt ein Server einen bereits angemeldeten Benutzer?
- Wo wird der Authentifizierungszustand gespeichert?
- Wie werden Zugriffsrechte überprüft?
- Welche Informationen dürfen wie zwischen welchen verschiedenen Komponenten übertragen werden?
- Wie lassen sich Identitäten in einem Web-Flow sicher nachweisen?
- Wie verhindern wir wirksam den Missbrauch gestohlener Sicherheitsartefakte?
Ob klassische Webanwendung, Single Page Application, native Smartphone-App oder Microservice-Landschaft – die zugrunde liegenden Prinzipien unterscheiden sich deutlich weniger, als häufig angenommen wird. Wenn Du die Standards kennst und weisst für welche Komponenten diese relevant sind, kannst Du Webanwendungen und Web-Flows auf IT Sicherheit validieren und selbst sichere Web-Services gestalten.
Wer Cookies, Sessions und Tokens versteht, versteht einen wesentlichen Teil moderner Softwarearchitektur.
Der Token Flow beginnt nicht beim Token
Viele Einsteiger beschäftigen sich zuerst mit JSON Web Tokens (JWT), OAuth oder OpenID Connect. Tatsächlich beginnt Authentifizierung jedoch deutlich früher.
Zunächst kommunizieren Client und Server über das zustandslose HTTP-Protokoll. Jeder Request wird zunächst unabhängig von allen vorherigen Requests verarbeitet. Erst zusätzliche Mechanismen ermöglichen es einem Server, mehrere Requests demselben Benutzer zuzuordnen und einen dauerhaften Nutzungskontext aufzubauen.
Genau hier kommen Cookies, Sessions und Tokens ins Spiel.
Sie verfolgen unterschiedliche Ziele und ergänzen sich gegenseitig. Je besser du die einzelnen Standards und Komponenten kennst, desto sicherer wirst Du darin diesen oft komplexen Token-Flow zu verstehen und zu handeln.
Session ID – Session State und Session Cookie
Token, Session & Cookie – Drei Begriffe – drei völlig unterschiedliche Aufgaben
Ein häufiger Irrtum besteht darin, Cookies, Sessions und Tokens als verschiedene Namen für dieselbe Technologie zu betrachten.
Tatsächlich erfüllen sie vollkommen unterschiedliche Aufgaben.
Cookies sind Transport- und Speichermedien des Browsers.
Sessions beschreiben einen serverseitig oder logisch verwalteten Nutzungskontext.
Tokens stellen kryptografisch und meist logisch abgesicherte Sicherheitsartefakte dar, mit denen Identitäten oder Berechtigungen nachgewiesen werden können.
Erst das richtige Zusammenspiel dieser drei Konzepte ermöglicht sichere Authentifizierungs- und Autorisierungsverfahren.
Moderne Authentifizierung ist immer IT Architektur
Die wichtigste Erkenntnis dieses Videos lautet deshalb:
Authentifizierung in Web-Komponenten und Web-Services ist das Ergebnis einer durchdachten IT-Architektur im standardkonformen Zusammenspiel unterschiedlicher Komponenten!
Dabei sind immer Fragen wie die folgenden relevant:
- Welche Komponente erzeugt einen Sicherheitsnachweis?
- Wo wird dieser gespeichert?
- Welche Instanz überprüft ihn?
- Welche Informationen werden zwischen Browser, Backend und APIs übertragen?
- Wann verliert ein Sicherheitsartefakt seine Gültigkeit?
- Wie wird Missbrauch verhindert?
- Welche Risiken entstehen durch Replay-Angriffe oder Cross-Site-Angriffe?
Diese Architekturentscheidungen bestimmen letztlich das Sicherheitsniveau einer Anwendung.
Die Sicherheitsarchitektur einer (Web-)Anwendung orientiert sich dabei ebenso an funktionalen Anforderungen wie an etablierten Sicherheitsstandards und regulatorische Vorgaben. In Deutschland bilden insbesondere der BSI IT-Grundschutz sowie die Technischen Richtlinien für kryptographische Verfahren des BSI wichtige Referenzwerke für den Entwurf, die Bewertung und den Betrieb sicherer Authentifizierungs- und Autorisierungslösungen.
Das geeignete Authentifizierungsverfahren hängt immer vom erforderlichen Schutzbedarf ab. Besonders schützenswerte Systeme – beispielsweise im Gesundheitswesen, im Finanzsektor oder bei staatlichen Identitätslösungen – erfordern zusätzliche Maßnahmen wie Multi-Faktor-Authentifizierung, kryptografisch gebundene Tokens (DPoP oder mTLS), Hardware-Sicherheitsmodule (HSM) oder qualifizierte Vertrauensdienste.
Von klassischen Sessions bis zu modernen Zero-Trust-Architekturen
Während klassische Webanwendungen häufig serverseitige Sessions verwenden, setzen moderne IT Architekturen zunehmend auf standardisierte Identitätsprotokolle wie OAuth 2.0 und OpenID Connect.
Access Tokens, Refresh Tokens und ID Tokens übernehmen dabei unterschiedliche Aufgaben.
Gleichzeitig entstehen neue Sicherheitsmechanismen wie DPoP (Demonstration of Proof-of-Possession) oder mTLS (Mutual TLS), die den Missbrauch gestohlener Bearer Tokens erschweren, indem sie einen Token kryptografisch an einen legitimen Client binden.
Authentifizierung entwickelt sich mit ihren Standards kontinuierlich weiter und orientiert sich dabei immer stärker an Zero-Trust-Prinzipien.
Für wen ist dieses Video geeignet?
Dieses Video richtet sich an:
- Softwareentwickler*innen
- Software- und IT-Architekt*innen
- Backend- und Frontend-Entwickler*innen
- API-Designer*innen
- DevOps- und Plattform-Teams
- Cybersecurity-Experten
- Studierende der Informatik
- alle, die OAuth, OpenID Connect und moderne Web-Sicherheit besser verstehen möchten.
Unabhängig davon, ob Du REST-APIs entwickelst, eine Web-App oder einen Service über eine Cloud-Plattform betreibst oder Dich erstmals mit Token Flows beschäftigst – die vermittelten Grundlagen bilden das Fundament jeder modernen Software- und IT Sicherheitsarchitektur.
Warum HTTP zustandslos ist
Das Hypertext Transfer Protocol (HTTP) bildet seit Jahrzehnten die Grundlage quasi jeder Webanwendung. Eine seiner wichtigsten Eigenschaften besteht darin, dass jeder HTTP-Request unabhängig von vorherigen Requests verarbeitet wird. Der Server speichert zwischen zwei Anfragen standardmäßig keinen Nutzungskontext.
Dadurch lässt sich ein Webserver sehr effizient skalieren, denn jede Anfrage kann grundsätzlich von jeder beliebigen Serverinstanz verarbeitet werden. Gleichzeitig entsteht jedoch ein offensichtliches Problem: Der Server erkennt ohne zusätzliche Informationen nicht, ob zwei Requests vom selben Benutzer stammen oder von völlig unterschiedlichen Clients.
Genau an dieser Stelle werden Konzepte wie Cookies, Sessions und Tokens relevant. Sie ergänzen das zustandslose HTTP-Protokoll um Mechanismen, mit denen ein Benutzer oder ein Nutzungskontext über mehrere Requests hinweg sicher wiedererkannt werden kann.
Cookies – Transport- und Speichermedium des Browsers
Cookies gehören zu den ältesten Mechanismen moderner Webanwendungen und werden häufig missverstanden. Ein Cookie ist zunächst weder ein Login noch eine Session und auch kein Token. Auch wenn Cookies oft mit Tracking gleichgesetzt werden handelt es sich zunächst vielmehr um einen standardisierten Speicher- und Transportmechanismus des Browsers.
Ein Webserver kann einem Browser ein Cookie zusammen mit einer HTTP-Response übermitteln. Der Browser speichert dieses Cookie und sendet es bei späteren Requests – abhängig von verschiedenen Regeln – automatisch wieder an den Server zurück.
Cookies: Technical Necessity or Tracking?
Welche Informationen in einem Cookie gespeichert werden, entscheidet die jeweilige Anwendung. Häufig enthält ein Cookie lediglich eine Session-ID oder einen anderen Verweis auf serverseitige Informationen. Ebenso kann ein Cookie Spracheinstellungen, Benutzereinstellungen oder andere nicht sicherheitskritische Daten enthalten.
Entgegen einer weit verbreiteten Annahme dienen Cookies nicht automatisch dem Tracking oder Marketing. Viele sicherheitsrelevante Webanwendungen verwenden Cookies ausschließlich für technisch notwendige Funktionen. Oft werden Cookies aber auch für Tracking und Marketing verfolgt. Das liegt unter anderem daran, dass ihre technischen Eigenschaften dafür gerade prädestiniert sind…
Sessions – Der wiedererkannte Nutzungskontext
Während Cookies lediglich Daten transportieren können, beschreibt eine Session den wiedererkannten Nutzungskontext eines Benutzers.
Nachdem sich ein Benutzer erfolgreich authentifiziert hat, erzeugt der Server häufig eine neue Session und verknüpft sie mit einer eindeutigen Session-ID. Diese Session enthält beispielsweise Informationen über den angemeldeten Benutzer, seine Berechtigungen oder weitere serverseitige Zustände.
Die Session selbst befindet sich typischerweise nicht im Browser, sondern im Backend oder in einem zentralen Session Store. Der Browser kennt häufig lediglich die Session-ID, welche über ein Cookie transportiert wird.
Dieses Architekturprinzip ermöglicht es, sensible Informationen serverseitig zu verwalten und bei Bedarf jederzeit zu ändern oder vollständig zu invalidieren.
Invalidieren bezieht sich auf den Lebenszyklus einer Session und bedeutet:
- Session beenden
- Session löschen
- Session-ID ungültig machen
- Benutzer abmelden
- Zugriff entziehen
Authentication und Authorization verständlich erklärt
Authentication und Authorization werden häufig verwechselt, beschreiben jedoch zwei unterschiedliche Fragestellungen.
Die Authentifizierung (Authentication) beantwortet die Frage:
Wer bist Du?
Hier wird die Identität eines Benutzers überprüft. Dies kann beispielsweise über Benutzername und Passwort, Multi-Faktor-Authentifizierung, Passkeys oder andere Verfahren erfolgen.
Die Autorisierung (Authorization) beantwortet dagegen die Frage:
Was darfst Du?
Erst nachdem eine Identität festgestellt wurde, können Berechtigungen geprüft werden. Dabei entscheidet eine Anwendung beispielsweise, ob ein Benutzer auf bestimmte Daten zugreifen oder eine bestimmte Funktion ausführen darf.
Diese Trennung bildet die Grundlage nahezu aller modernen Identitätsplattformen und Sicherheitsarchitekturen.
Authorization – Autorisierung
Access Token, Refresh Token und ID Token
Moderne Identitätsprotokolle unterscheiden verschiedene Token-Typen mit jeweils klar definierten Aufgaben.
Ein Access Token dient dazu, Zugriffe auf geschützte Ressourcen zu autorisieren. APIs prüfen anhand dieses Tokens, ob ein Client die angeforderte Operation durchführen darf.
Ein Refresh Token besitzt eine andere Aufgabe. Es ermöglicht die kontrollierte Ausstellung neuer Access Tokens, ohne dass sich der Benutzer erneut authentifizieren muss.
Ein ID Token beschreibt dagegen die erfolgreich authentifizierte Identität eines Benutzers und wird insbesondere im Zusammenhang mit OpenID Connect verwendet.
Diese Token erfüllen unterschiedliche Zwecke und sollten weder verwechselt noch gegenseitig ersetzt werden.
JSON Web Token
JWT – Format ist ein Datenformat und spielt innerhalb eines Sicherheitskonzept eine tragende Rolle
JSON Web Token (JWT) gehört zu den bekanntesten Begriffen moderner Webentwicklung. Mitunter wird sogar angenommen, ein JWT sei automatisch sicher oder sogar selbst ein Authentifizierungsverfahren. Dem ist nicht so; vielmehr übernehmen JSON Web Token eine tragende Rolle für Webanwendungen.
Tatsächlich beschreibt JWT zunächst lediglich ein standardisiertes Datenformat zur Übertragung strukturierter Claims. Das kannst Du Dir am besten wie folgt merken:
Ein Claim erhebt einen Anspruch. Ob dieser Anspruch (eines Requests) akzeptiert wird, entscheidet der Empfänger (Server / Backend).
Ein Claim beschreibt Eigenschaften oder Berechtigungen – was daraus erlaubt wird, entscheidet die Anwendung.
Claim = „Ich behaupte, dass…“ – Vertrauen entsteht erst durch die Signatur und die Validierung.
Claims machen Aussagen – Policies treffen Entscheidungen.
Ein Claim beschreibt also was ich darf. Ein JWT definiert solche Claims und kann signiert oder verschlüsselt werden und verschiedene Informationen enthalten.
Ob ein JWT sicher eingesetzt wird, hängt jedoch nicht vom Format selbst ab, sondern von seiner korrekten Erstellung, Signaturprüfung, Gültigkeitsprüfung, Lebensdauer sowie der sicheren Verwaltung kryptografischer Schlüssel.
Ein JWT ersetzt weder OAuth 2.0 noch OpenID Connect oder andere Sicherheitsprotokolle; erst in Verbindung mit ihnen wird es sicher.
CSRF und XSS – Typische Angriffe auf Webanwendungen
Mit zunehmender Komplexität moderner Webanwendungen entstehen auch neue Angriffsvektoren.
Cross-Site Request Forgery (CSRF) versucht, einen Browser dazu zu bringen, ungewollte Requests an eine vertrauenswürdige Anwendung zu senden. Da Browser Cookies unter bestimmten Bedingungen automatisch mitsenden, können dadurch unerwünschte Aktionen ausgelöst werden.
Cross-Site Scripting (XSS) verfolgt einen anderen Ansatz. Hier versuchen Angreifer, schädlichen JavaScript-Code in eine Anwendung einzuschleusen. Gelingt dies, können unter anderem Benutzereingaben manipuliert oder Sicherheitsinformationen abgegriffen werden.
Moderne Webanwendungen müssen beide Angriffsszenarien berücksichtigen und geeignete Schutzmechanismen implementieren.
HttpOnly, Secure und SameSite Cookies
Nicht jedes Cookie besitzt dieselben Sicherheitseigenschaften.
Mit dem Attribut HttpOnly kann verhindert werden, dass clientseitiges JavaScript auf ein Cookie zugreifen kann. Dadurch sinkt unter anderem das Risiko bestimmter XSS-Angriffe.
Das Attribut Secure stellt sicher, dass ein Cookie ausschließlich über verschlüsselte HTTPS-Verbindungen übertragen wird.
SameSite definiert schließlich, unter welchen Bedingungen Browser Cookies bei Cross-Site-Anfragen mitsenden dürfen. Je nach gewählter Konfiguration lassen sich dadurch verschiedene CSRF-Angriffe deutlich erschweren.
Diese Attribute gehören heute zu den wichtigsten Sicherheitsmechanismen moderner Browser.
Backend for Frontend (BFF) und serverseitiges Token-Management
Das Backend-for-Frontend-Muster verfolgt das Ziel, sicherheitskritische Token möglichst nicht dauerhaft im Browser zu speichern.
Stattdessen kommuniziert der Browser häufig ausschließlich mit einem speziell für ihn vorgesehenen Backend. Dieses Backend verwaltet Access Tokens oder Refresh Tokens serverseitig und stellt dem Browser lediglich einen technisch notwendigen Nutzungskontext, beispielsweise über ein Session-Cookie, zur Verfügung.
Dadurch reduziert sich die direkte Angriffsfläche im Browser erheblich. Gleichzeitig lassen sich Token-Lebenszyklen, Erneuerungen und Sperrungen zentral kontrollieren.
Ein Backend for Frontend ersetzt jedoch keine Sicherheitsmaßnahmen gegen CSRF, XSS oder andere Angriffe. Vielmehr ergänzt es eine ganzheitliche Sicherheitsarchitektur.
DPoP, mTLS und sender-constrained Tokens
Klassische Bearer Tokens besitzen eine wesentliche Eigenschaft: Wer den Token besitzt, kann ihn grundsätzlich verwenden.
Moderne Verfahren versuchen deshalb, Tokens kryptografisch an einen bestimmten Client zu binden.
Demonstration of Proof-of-Possession (DPoP) ergänzt OAuth um einen kryptografischen Besitznachweis. Der Client muss nachweisen, dass er den zugehörigen privaten Schlüssel tatsächlich besitzt.
Mutual TLS (mTLS) verfolgt einen ähnlichen Ansatz auf Transportebene. Dabei authentifizieren sich Client und Server gegenseitig mithilfe von Zertifikaten.
Beide Verfahren erschweren Replay-Angriffe erheblich und bilden wichtige Bausteine moderner Zero-Trust-Architekturen.
Zusammenfassung: Moderne Web-Authentifizierung als Gesamtsystem
Cookies, Sessions und Tokens erfüllen unterschiedliche Aufgaben und ergänzen sich gegenseitig. Erst das Zusammenspiel aus Browser, Backend, Authorization Server, APIs und standardisierten Identitätsprotokollen ermöglicht sichere digitale Identitäten und moderne Webanwendungen.
Wer die zugrunde liegenden Architekturprinzipien versteht, erkennt schnell, dass moderne Authentifizierung weit mehr ist als ein einzelnes Login oder ein JWT. Entscheidend ist immer die Gesamtlösung: Welche Komponente erzeugt einen Sicherheitsnachweis, wo wird dieser gespeichert, wie wird er übertragen, welche Instanz prüft ihn und wie wird Missbrauch verhindert?
Genau deshalb behandelt dieses Video nicht einzelne Technologien isoliert, sondern den vollständigen Token Flow zwischen Browser, Backend und APIs. Dieses Verständnis bildet die Grundlage für zahlreiche weiterführende Themen – von OAuth 2.0 und OpenID Connect über Zero Trust bis hin zu digitalen Identitäten, Kryptografie und sicheren Softwarearchitekturen.
