Das Internet-Lexikon

OAuth vs. JWT

Zwei Begriffe, die im Kontext von API-Authentifizierung häufig gemeinsam auftauchen, aber völlig unterschiedliche Fragen beantworten - und wie sie in der Praxis zusammenspielen, samt der Sonderfälle, an denen dieses Zusammenspiel oft missverstanden wird.

Kaum zwei Begriffe werden im Kontext von API-Sicherheit so häufig in einem Atemzug genannt - und so häufig verwechselt - wie OAuth und JWT. Dabei lösen sie grundverschiedene Probleme: Das eine ist ein Ablaufprotokoll, das andere ein Datenformat. Dieser Artikel klärt nicht nur die Grundunterscheidung, sondern auch die praktischen Sonderfälle, an denen dieses Zusammenspiel in echten Systemen tatsächlich knirscht.

1. Was OAuth regelt

OAuth ist ein Autorisierungsprotokoll: Es definiert einen standardisierten Ablauf, mit dem eine Anwendung (Client) im Namen eines Nutzers (Resource Owner) begrenzten Zugriff auf Ressourcen bei einem anderen Dienst (Resource Server) erhält, ohne dass der Nutzer sein Passwort an die Anwendung weitergibt. Am Ende dieses Ablaufs stellt ein Autorisierungsserver (Authorization Server) einen Token aus, mit dem die Anwendung fortan im Namen des Nutzers Anfragen stellen kann. OAuth beschreibt also den Prozess - wer wem wofür Zugriff erteilt - nicht das technische Format des dabei ausgestellten Tokens.

2. Was JWT regelt

JWT ist dagegen kein Protokoll, sondern ein Datenformat: ein kompaktes, signiertes Token, das aus drei durch Punkte getrennten, Base64Url-kodierten Teilen besteht - Header, Payload und Signatur. Die Payload trägt Informationen wie Nutzer-ID, Berechtigungen oder Ablaufzeit. Wichtig dabei: Die Signatur macht ein JWT fälschungssicher, aber nicht geheim - Header und Payload lassen sich ohne Kenntnis eines Secrets decodieren und lesen. Wer vertrauliche Informationen in einem JWT transportiert, verschickt sie damit faktisch im Klartext, nur gegen nachträgliche Manipulation abgesichert.

3. Wie beide in der Praxis zusammenspielen

In der Praxis wird JWT häufig als das konkrete Token-Format innerhalb eines OAuth-Ablaufs verwendet: Nach einer erfolgreichen OAuth-Autorisierung stellt der Server einen Access Token aus - und dieser Token ist in vielen Implementierungen ein JWT. OAuth selbst schreibt dieses Format aber nicht zwingend vor; es könnten ebenso undurchsichtige, zufällig generierte Tokens verwendet werden, die serverseitig gegen eine Datenbank geprüft werden (Opaque Tokens). Bei OpenID Connect, einer verbreiteten Erweiterung von OAuth für Identitätsnachweise, ist das zusätzlich ausgestellte ID Token dagegen per Spezifikation als JWT definiert.

4. Der praktische Unterschied in der Fragestellung

Wer die Frage “Wie erlaube ich einer Anwendung sicher Zugriff auf einen anderen Dienst?” beantworten will, braucht OAuth. Wer die Frage “Wie verpacke und verifiziere ich Berechtigungsinformationen fälschungssicher?” beantworten will, braucht ein Tokenformat wie JWT - unabhängig davon, ob überhaupt ein OAuth-Ablauf im Spiel ist. Eine einzelne interne API kann JWTs zur Authentifizierung nutzen, ganz ohne jemals einen OAuth-Ablauf zu durchlaufen, etwa wenn ein eigener Login-Server selbst signierte Tokens ausstellt.

5. Das strukturelle Problem: JWT-Widerruf

Ein zentraler praktischer Unterschied zu klassischen Sitzungsmechanismen zeigt sich beim Widerruf: Ein einmal ausgestelltes JWT ist bis zu seinem Ablaufzeitpunkt gültig, sofern die Signatur stimmt - der ausstellende Server kann es nicht ohne Weiteres vorzeitig für ungültig erklären, da keine zentrale Instanz jedes ausgestellte Token einzeln nachhält. In der Praxis wird das meist durch kurze Lebensdauern kombiniert mit separat ausgestellten Refresh Tokens gelöst, die zentral widerrufen werden können, oder durch eine serverseitig geführte Sperrliste für kompromittierte Tokens - was aber wieder einen zentralen Speicher voraussetzt und den zustandslosen Vorteil von JWT teilweise aufgibt.

6. Ein häufig übersehenes Sicherheitsdetail

Ein JWT ist nicht automatisch sicher, nur weil es signiert ist - es kommt darauf an, dass die empfangende Seite die Signatur auch tatsächlich prüft und dabei den erwarteten Signaturalgorithmus erzwingt. Historisch wurden Implementierungen bekannt, die den im Token-Header selbst angegebenen Algorithmus ungeprüft übernahmen und dadurch mit einem im Header auf “kein Algorithmus” umgestellten, unsignierten Token ausgetrickst werden konnten. Die Lehre daraus: Der erwartete Algorithmus muss serverseitig fest vorgegeben sein, nicht aus dem eingehenden Token selbst übernommen werden.

7. Vergleich mit klassischen Sessions und Cookies

Klassische serverseitige Sessions, typischerweise über ein Cookie referenziert, speichern den eigentlichen Zustand zentral auf dem Server und übertragen nur eine Session-ID an den Client. Das macht Widerruf trivial (Eintrag löschen), erfordert aber einen zentralen, bei jeder Anfrage abzufragenden Speicher - der bei verteilten Systemen mit vielen Servern zum Flaschenhals werden kann. JWTs kehren dieses Verhältnis um: Der Zustand steckt im Token selbst, jeder Server kann ihn ohne zentrale Abfrage prüfen, dafür ist der vorzeitige Widerruf strukturell schwieriger.

8. Häufiger Irrtum in der Praxis

Ein verbreiteter Irrtum ist die Annahme, JWT sei per se sicherer oder moderner als klassische Session-Cookies. Tatsächlich hat jeder Ansatz eigene Kompromisse, wie in den vorangegangenen Abschnitten beschrieben - die Wahl hängt davon ab, ob Zustandslosigkeit (mehrere unabhängige Server, keine zentrale Session-Datenbank) oder einfacher Widerruf (etwa für sensible Anwendungen mit Bedarf an sofortiger Abmeldung) wichtiger ist.

9. Entscheidungshilfe

  • Soll eine Anwendung im Namen eines Nutzers auf einen fremden Dienst zugreifen? → OAuth regelt den Autorisierungsablauf; das dabei verwendete Tokenformat ist eine separate Entscheidung.
  • Soll ein selbst betriebenes System Berechtigungen fälschungssicher zwischen mehreren Diensten weitergeben, ohne bei jeder Anfrage eine zentrale Datenbank abzufragen? → JWT als Tokenformat, unabhängig von OAuth.
  • Ist sofortiger, zuverlässiger Widerruf einzelner Sitzungen wichtiger als Zustandslosigkeit? → Klassische serverseitige Session eher geeignet als ein reines JWT ohne zusätzliche Sperrliste.
  • Werden vertrauliche Daten transportiert? → Nicht ungeschützt in die JWT-Payload legen, da sie ohne Secret lesbar ist - nur die Signatur, nicht der Inhalt, ist geschützt.

Weiterführend