Authentifizierung richtig umsetzen: OAuth, JWT oder Sessions?

Kurz gefasst: Für die meisten Web-Anwendungen ist eine klassische Session mit sicherem, httpOnly-Cookie die einfachste und sicherste Form der Authentifizierung. JWT eignet sich, wenn mehrere Dienste oder mobile Apps Tokens ohne zentrale Abfrage prüfen müssen, bringt aber eigene Probleme beim Widerruf mit. OAuth 2.0 mit OpenID Connect ist der Standard, sobald Nutzer sich über Google, Microsoft oder einen zentralen Identity-Provider anmelden sollen. Viele Projekte fahren am besten mit einer bewährten Auth-Lösung statt einer Eigenentwicklung.

Authentifizierung und Autorisierung unterscheiden

Authentifizierung beantwortet die Frage, wer jemand ist. Autorisierung regelt, was diese Person darf. Beides wird oft vermischt, gehört aber in unterschiedliche Schichten. Ein Login mit Passwort und zweitem Faktor ist Authentifizierung. Dass eine Sachbearbeiterin nur die Aufträge ihrer Filiale sieht, ist Autorisierung und muss bei jeder Anfrage auf dem Server geprüft werden. Eine ausgeblendete Schaltfläche in der Oberfläche reicht dafür nicht.

Sessions: der unterschätzte Standard

Bei einer serverseitigen Session erhält der Browser nach dem Login eine zufällige Session-ID im Cookie. Die eigentlichen Daten liegen auf dem Server oder in einem Store wie Redis. Der Vorteil: Eine Session lässt sich jederzeit sofort beenden, etwa beim Logout, bei Passwortänderung oder wenn ein Konto gesperrt wird.

Das Cookie sollte mit HttpOnly gesetzt sein, damit JavaScript es nicht lesen kann, mit Secure, damit es nur über HTTPS übertragen wird, und mit SameSite=Lax oder Strict als Schutz gegen CSRF. Nach dem Login vergibt der Server eine neue Session-ID, um Session-Fixation zu verhindern. Für eine klassische Web-App mit eigenem Backend ist das in den meisten Fällen die beste Wahl.

JWT: wann Tokens sinnvoll sind

Ein JSON Web Token ist ein signiertes Datenpaket, das Informationen wie Nutzer-ID und Rollen enthält. Jeder Dienst mit dem passenden Schlüssel kann die Signatur prüfen, ohne eine Datenbank zu fragen. Das ist praktisch bei verteilten Systemen, APIs für mobile Apps oder wenn mehrere Backends dieselbe Identität nutzen.

Die Kehrseite: Ein ausgestelltes Token bleibt gültig, bis es abläuft. Deshalb arbeitet man mit kurzlebigen Access-Tokens von wenigen Minuten und längerlebigen Refresh-Tokens, die bei jeder Nutzung erneuert werden (Rotation). Wird ein altes Refresh-Token erneut verwendet, deutet das auf Diebstahl hin und die ganze Token-Familie wird gesperrt.

Typische Fehler sind Tokens im localStorage, wo jedes eingeschleuste Skript sie auslesen kann, fehlende Prüfung des Signaturalgorithmus und zu viele Daten im Token. Ein JWT ist signiert, aber nicht verschlüsselt. Wer es abfängt, kann den Inhalt lesen. Mehr zu solchen Angriffen finden Sie in unseren Grundlagen der Web-Sicherheit.

OAuth 2.0 und OpenID Connect

OAuth 2.0 ist ein Protokoll zur Delegation von Zugriffsrechten: Eine Anwendung darf im Namen eines Nutzers auf eine API zugreifen, ohne dessen Passwort zu kennen. Für den Login selbst ist OpenID Connect zuständig, eine Schicht auf OAuth, die ein ID-Token mit Identitätsinformationen liefert.

Für Web- und Mobile-Apps ist heute der Authorization Code Flow mit PKCE die empfohlene Variante. Der ältere Implicit Flow gilt als überholt, weil er Tokens in der URL überträgt. Sinnvoll ist OpenID Connect, wenn Mitarbeitende sich mit ihrem Microsoft-Konto anmelden sollen, wenn Sie Single Sign-on über mehrere Anwendungen brauchen oder wenn Kunden sich über Google oder Apple registrieren. Bei mobilen Apps kommen weitere Punkte hinzu, die wir unter Sicherheitslücken in mobilen Apps beschreiben.

Selbst bauen oder fertige Lösung nutzen?

Passwort-Hashing mit Argon2id oder bcrypt, Rate-Limiting gegen Brute-Force, Zwei-Faktor-Authentifizierung, Passkeys, Passwort-Reset, Kontosperrung, Audit-Logs: Eine vollständige Authentifizierung umfasst viel mehr als ein Login-Formular. Fertige Lösungen wie Keycloak, Auth.js, Supabase Auth oder kommerzielle Anbieter decken das ab und werden laufend gepflegt.

Für deutsche Unternehmen spielt dabei der Speicherort eine Rolle, denn Nutzerkonten sind personenbezogene Daten. Ein selbst gehostetes Keycloak oder ein Anbieter mit Rechenzentrum in der EU erleichtert die DSGVO-Konformität. Die Entscheidung gehört zu den frühen Architekturfragen, die sich später nur mühsam ändern lassen, wie unser Beitrag zu Architekturentscheidungen bei SaaS-Produkten zeigt.

Häufige Fragen (FAQ)

Ist JWT sicherer als eine Session?

Nein, keines der beiden Verfahren ist grundsätzlich sicherer. Sessions lassen sich leichter widerrufen und sind für klassische Web-Apps meist die bessere Wahl. JWT spielt seine Stärken aus, wenn mehrere Dienste Tokens unabhängig prüfen müssen.

Wo sollte ich Tokens im Browser speichern?

Am besten in einem httpOnly-Cookie mit Secure und SameSite. Dort kann JavaScript sie nicht auslesen, was den Schaden bei einer XSS-Lücke begrenzt. Der localStorage ist für Zugangsdaten ungeeignet.

Brauche ich Zwei-Faktor-Authentifizierung?

Für Konten mit Zugriff auf Kundendaten, Zahlungen oder Administration sollten Sie sie auf jeden Fall anbieten, für Admins verpflichtend machen. Passkeys sind eine komfortable Alternative, die Phishing deutlich erschwert und von allen großen Plattformen unterstützt wird.

Was ist PKCE und warum ist es wichtig?

PKCE ist eine Erweiterung für den OAuth Authorization Code Flow. Sie verhindert, dass ein abgefangener Autorisierungscode von einem Angreifer eingelöst werden kann. Für öffentliche Clients wie Single-Page-Apps und mobile Apps ist PKCE heute Pflicht, und auch serverseitige Anwendungen sollten es nutzen.

Fazit

Gute Authentifizierung beginnt mit der Wahl des einfachsten Verfahrens, das Ihre Architektur trägt, und nicht mit dem modernsten. Für viele Anwendungen ist das eine Session mit sauber gesetztem Cookie, ergänzt um Zwei-Faktor-Login und eine erprobte Bibliothek statt eigener Kryptografie.

Wenn Sie eine Anwendung mit Benutzerkonten planen oder Ihr bestehendes Login absichern möchten, sprechen Sie mit uns über Webentwicklung.