JWT vs OAuth: Wichtige Unterschiede, wie sie zusammenarbeiten und Best Practices

Wenn du neu im Bereich Authentifizierung bist und eine App entwickelst, die Logins, Zahlungen oder Benutzerdaten verarbeitet, bist du wahrscheinlich auf die Begriffe JWT und OAuth gestoßen. Sie klingen vielleicht nach komplexen Themen nur für das Backend, aber sie sind nicht nur für Sicherheitsexperten relevant.

Mit APIs, Drittanbieter-Integrationen und neuen Technologien wie KI, MCP und agentenbasierten Systemen haben diese beiden Konzepte direkten Einfluss auf die Benutzerfreundlichkeit, Sicherheit und das Wachstum deines Produkts. Wenn du die Grundlagen verstehst, kannst du:

• Funktionen von Anfang an sicher gestalten
• Effektiv mit deinem Entwicklerteam kommunizieren
• Bessere Produktentscheidungen rund um Authentifizierung und Nutzerflüsse treffen
• Teure Sicherheitsfehler vermeiden, die das Vertrauen der Nutzer beschädigen

Zum Beispiel basiert das Autorisierungssystem in der aktuellen MCP-Spezifikation auf bewährten Standards:

• OAuth 2.1 IETF-Entwurf (draft-ietf-oauth-v2-1-13)
• OAuth 2.0 Authorization Server Metadata (RFC8414)
• OAuth 2.0 Dynamic Client Registration Protocol (RFC7591)
• OAuth 2.0 Protected Resource Metadata (RFC9728)

Warum das wichtig ist#

Selbst wenn du nie Backend-Code schreibst:

• Entwickler lernen, wie man APIs absichert, Sitzungen verwaltet und Drittanbieterdienste integriert.
• Produktmanager gewinnen das Vokabular, um Login-Flows, Integrationen und Compliance mit Teams und Partnern zu besprechen.
• Gründer und Early-Stage-Teams vermeiden es, brüchige Login-Systeme zu bauen, die bei Integrationen versagen oder zu Sicherheitslücken führen.

JWT vs OAuth: Die zwei Kernkonzepte#

JWT (JSON Web Token) und OAuth (Open Authorization) werden oft zusammen verwendet, dienen aber unterschiedlichen Zwecken.

Denke daran so:

• OAuth ist die Art, wie du jemandem die Schlüssel gibst, aber nur für die Räume, in die er eintreten darf.
• JWT ist die Ausweiskarte, die er bei sich trägt, als Nachweis darüber, wer er ist und was er darf.

Im nächsten Abschnitt stellen wir sie nebeneinander gegenüber, damit du die Unterschiede und das Zusammenspiel klar erkennst.

Was ist OAuth 2.0?#

OAuth 2.0 ist ein weit verbreitetes Autorisierungs-Framework, das es einer Anwendung (dem Client) ermöglicht, auf die Ressourcen eines Nutzers mit eingeschränkten Berechtigungen zuzugreifen, ohne die Anmeldedaten (wie Passwörter) preiszugeben.

Zentrale Rollen in OAuth#

• Client: Die Anwendung, die Zugriff anfordert.
• Resource Owner: Meist der Benutzer, der Berechtigungen erteilt.
• Authorization Server: Gibt nach der Autorisierung Zugriffstokens aus.
• Resource Server: Beherbergt die geschützten Ressourcen und prüft Tokens.

Häufige OAuth Grant Types (Flows)#

• Authorization Code Grant: Am sichersten und empfohlen, besonders mit PKCE für Browser-, SPA- und Mobile Apps.
• Implicit Grant: In OAuth 2.1 aus Sicherheitsgründen nicht mehr empfohlen.
• Resource Owner Password Credentials (ROPC): Tauscht Benutzername und Passwort direkt gegen Tokens aus; weniger sicher.
• Client Credentials Grant: Für Server-zu-Server- oder Machine-to-Machine-Kommunikation.
• Device Flow: Für Geräte ohne Tastatur (z. B. Smart-TVs), bei denen der Nutzer am Zweitgerät autorisiert.

Was ist JWT (JSON Web Token)?#

Ein JWT ist ein offener Standard (RFC 7519) für die sichere Übertragung von Claims zwischen zwei Parteien in einem kompakten, URL-sicheren Format.

Aufbau eines JWT#

Ein JWT besteht aus drei base64url-codierten Teilen, die durch Punkte (.) getrennt sind:

1. Header: Gibt Algorithmus (z. B. HS256, RS256) und Token-Typ (JWT) an.
2. Payload: Enthält Claims, wie beispielsweise:
   • iss (issuer)
   • sub (subject, z. B. Benutzer-ID)
   • aud (audience)
   • exp (Ablaufzeitpunkt)
   • Benutzerdefinierte Claims nach Bedarf
3. Signature – Prüft, ob das Token nicht manipuliert wurde.

Beispiel:

Ein JWT-Beispiel#

Hier ein Beispiel für ein typisches JWT in kodierter Form mit der dekodierten Struktur, damit du siehst, was die einzelnen Teile bedeuten.

Kodiertes JWT (Base64URL)

Dies besteht aus drei Teilen, getrennt durch Punkte: header.payload.signature

Dekodierte Struktur

• Header

• Payload

Die Payload enthält Claims

• Signature

Die Signatur stellt sicher, dass das Token nicht manipuliert wurde.

Wesentliche Eigenschaften#

• Eigenständig: Alle benötigten Informationen sind im Token enthalten.
• Zustandslos: Keine serverseitige Session-Speicherung notwendig.
• Signiert: (und optional verschlüsselt) zur Gewährleistung der Echtheit.

JWT vs OAuth: Zentrale Unterschiede#

Kurz gesagt:

• JWT ist der Behälter: wie ein Pass mit Identitätsdaten.
• OAuth ist das System: wie die Einwanderungskontrolle, die entscheidet, wer den Pass kriegt und was damit möglich ist.

Wann JWT alleine verwenden#

Verwende JWT alleine, wenn:

• Single-System-Authentifizierung, bei der deine App Tokens selbst vergibt und prüft, ohne externe Identity-Provider einzubinden.
• Zustandsloses Session-Management zur Überprüfung der Nutzeridentität, ohne Sitzungsdaten auf dem Server zu speichern.
• Einfache API-Authentifizierung für interne APIs, bei denen nur grundlegende Zugriffsrechte benötigt werden und keine komplexen Einverständnis-Flows.
• Performance-orientierte Prüfung, sodass Ressourcenserver Tokens lokal validieren können, ohne den Auth-Server zu kontaktieren.

Beispiel:

Eine Single-Page-App und ein Backend-API, die du besitzt. Das API vergibt ein JWT mit sub (Benutzer-ID), Rolle und exp (Ablaufzeitpunkt) Claims.

Wann OAuth alleine verwenden#

Verwende OAuth ohne JWT, wenn:

• Du keine eigenständigen Tokens benötigst und auch undurchsichtige Tokens (die nachgeschlagen werden müssen) akzeptabel sind.
• Du möchtest, dass der Ressourcenserver vor der Freigabe von Zugriff immer beim Authorization Server prüft.
• Du dich in einer Legacy- oder regulierten Umgebung befindest, in der JWT nicht geeignet ist.
• Das Ziel delegierte Autorisierung ist, z. B. für die sichere Vergabe begrenzter Zugriffsrechte an Drittanbieter-Apps.

Beispiel:

Ein API, das undurchsichtige Zugriffstokens vergibt und jede Anfrage durch Rückfrage beim Authorization Server prüft.

Wann JWT und OAuth gemeinsam verwenden#

Verwende beide zusammen, wenn:

• Du mehrere Services oder APIs hast und OAuth für den sicheren Flow sowie JWT für verifizierbare Tokens zwischen Diensten nutzen willst.
• Du Drittfirmen-Login anbietest (z. B. „Mit Google anmelden“), wobei OAuth das Einverständnis abwickelt und JWT das Zugriffs- oder ID-Token trägt.
• Du eine Microservices-Architektur betreibst und jeder Service JWTs lokal validieren kann.
• Du Skalierbarkeit durch das Delegationsmodell von OAuth und die zustandslose Prüfung von JWT benötigst.

Beispiel:

Deine App lässt Nutzer sich mit Google anmelden. OAuth steuert den Autorisierungsprozess, Google gibt ein JWT-Zugriffstoken aus und deine APIs prüfen es lokal, bevor sie Daten ausgeben.

Wie JWT und OAuth zusammenarbeiten#

In modernen Authentifizierungs- und Autorisierungssystemen:

1. OAuth steuert den Flow zur Zugriffserteilung.
2. Der Authorization Server stellt ein Zugriffstoken aus: meist ein JWT.
3. Das JWT wird bei API-Anfragen mitgesendet, um Identität und Rechte nachzuweisen.

Spezielle Tokens in OAuth#

• ID-Token: In OpenID Connect zum Nachweis der Nutzeridentität; immer ein JWT.
• Access-Token: Kann JWT oder undurchsichtiges Token sein.

Best Practices für JWTs und OAuth#

• Verwende HTTPS, um Tokens beim Transport zu schützen.
• Setze kurze Gültigkeiten für JWTs; verwende Refresh Tokens für längere Sitzungen.
  • https://auth.wiki/offline-access.
• Validiere die Signatur, bevor du Claims vertraust.
• Prüfe den aud Claim, um sicherzustellen, dass das Token tatsächlich für deine App bestimmt ist.
• Speichere Tokens nicht in localStorage, wenn ein XSS-Risiko besteht; nutze bevorzugt sichere Cookies.

Fazit#

• OAuth 2.0 definiert, wie Tokens erhalten und verwendet werden.
• JWT definiert, wie ein Token aussieht und wie es Informationen enthält.
• Sie sind komplementär, nicht austauschbar.

Die meisten modernen APIs nutzen OAuth für Auth-Flows und JWT für das Tokenformat. Wenn du beide verstehst, kannst du sichere, skalierbare Authentifizierungssysteme bauen.