OAuth 2.0 und Token-Sicherheit für ERP-Schnittstellen

OAuth 2.0 ist der etablierte Standard für delegierte Autorisierung. Statt ein dauerhaftes Passwort weiterzugeben, holt sich ein Client bei einem Autorisierungsserver ein zeitlich begrenztes Access Token ab und legt dieses bei jedem Aufruf der Schnittstelle vor. OAuth kennt mehrere Abläufe, sogenannte Grant Types, je nachdem, ob ein Mensch im Browser beteiligt ist oder zwei Systeme direkt miteinander sprechen. Für die Kommunikation zwischen Shop, Middleware und ERP -- also Maschine zu Maschine ohne interaktiven Nutzer -- ist der Client-Credentials-Flow vorgesehen.

Im Client-Credentials-Flow authentifiziert sich der Client direkt am Token-Endpunkt des Autorisierungsservers und erhält ein Access Token zurück. Die Anmeldung erfolgt nicht mehr über ein Passwort im Klartext, sondern idealerweise über ein Client-Zertifikat. So sieht ein solcher Token-Request im Kern aus:

Der zentrale Ort für diese Logik ist in der Praxis die Middleware: Sie holt Tokens ab, erneuert sie rechtzeitig, hält Zertifikate vor und setzt die Absicherung einheitlich durch, statt sie in jeder einzelnen Punkt-zu-Punkt-Verbindung erneut zu implementieren. Das Access Token, das der Server ausstellt, ist bewusst kurzlebig und trägt nur die Berechtigungen, die der jeweilige Prozess wirklich braucht.

Genau hier setzt die aktuelle Sicherheitsempfehlung an. RFC 9700, die seit Januar 2025 gültige Best Current Practice für OAuth-2.0-Sicherheit, empfiehlt, Access Tokens an ihren Absender zu binden (IETF RFC 9700). Ein solches sender-constrained Token ist nur nutzbar, wenn der Aufrufer zusätzlich den Besitz eines bestimmten Geheimnisses nachweist -- eines privaten Schlüssels oder eines Zertifikats. Ein gestohlenes Token allein bringt einem Angreifer dann nichts mehr. RFC 9700 nennt zwei standardisierte Verfahren dafür: Mutual TLS nach RFC 8705 und Demonstrating Proof of Possession, kurz DPoP, nach RFC 9449 (IETF RFC 9700).

Bei mutual TLS weisen sich beide Seiten mit Zertifikaten aus -- nicht nur der Server gegenüber dem Client, sondern auch der Client gegenüber dem Server. Das ausgestellte Token wird an den öffentlichen Schlüssel des Client-Zertifikats gebunden; der Resource Server akzeptiert es nur über dieselbe zertifikatsgesicherte Verbindung. DPoP verfolgt dasselbe Ziel auf Anwendungsebene: Der Client erzeugt pro Anfrage einen signierten Nachweis mit seinem privaten Schlüssel, den der Server gegen den im Token hinterlegten Schlüssel prüft. Beide Verfahren machen ein abgefangenes Token wertlos, unterscheiden sich aber in Infrastruktur und Einsatzprofil.

Für die klassische Server-zu-Server-Verbindung zwischen Middleware und ERP -- etwa einer SAP-Anbindung -- ist mutual TLS oft die naheliegende Wahl, weil beide Seiten ohnehin verwaltet werden und eine Zertifikatsstruktur besteht. DPoP spielt seine Stärke dort aus, wo eine ausgewachsene Client-PKI zu aufwendig wäre. Entscheidend ist nicht die Wahl des einen oder anderen Verfahrens, sondern dass Tokens überhaupt an ihren Absender gebunden werden, statt als frei übertragbares Bargeld durch die Systeme zu wandern.

Selbst ein kurzlebiges, gebundenes Token sollte nur so viel dürfen wie nötig. Genau das leisten Scopes: Sie schränken ein Token auf eine eng umrissene Menge von Rechten ein. Ein Prozess, der nur Bestellungen aus dem Shop ins ERP übertragen soll, braucht kein Token mit Vollzugriff auf Kundenstammdaten und Preise. RFC 9700 rät ausdrücklich dazu, Scopes minimal zu halten und nur die tatsächlich benötigten Berechtigungen zu vergeben (IETF RFC 9700). Dieses Least-Privilege-Prinzip begrenzt den Schaden, falls ein Token doch einmal kompromittiert wird.

Die Wirkung reicht bis zur fehlerhaften Objekt-Autorisierung, die OWASP auf Platz 1 der API Security Top 10 führt (OWASP). Ein eng gefasstes Token, das nur lesenden Zugriff auf Bestellungen erlaubt, kann keine Preise ändern und keine Kundendatensätze löschen, selbst wenn ein Angreifer es erbeutet. Scopes ersetzen die Berechtigungsprüfung pro Datensatz nicht, aber sie verkleinern die Angriffsfläche jedes einzelnen Tokens erheblich. Wie sich eine solche Berechtigungsschicht zentral bündeln lässt, zeigt der Vergleich REST-API und Middleware.

Der Weg von einer gewachsenen Anbindung mit statischem Schlüssel zu einer token-basierten Schnittstelle lässt sich schrittweise gehen, ohne den laufenden Betrieb zu unterbrechen -- als Teil einer geordneten Systemintegration. Am Anfang steht keine große Neuentwicklung, sondern eine Bestandsaufnahme: Welche Schnittstellen existieren, wie authentifizieren sie sich heute und welche Daten fließen über sie. Aus diesem Befund ergibt sich die Reihenfolge -- die Verbindungen mit den weitreichendsten Rechten und den sensibelsten Daten zuerst.

Wer die Absicherung in eine breitere Integrationsstrategie einbettet, findet weiterführende Ansätze in unserem Beitrag zur Anbindung der JTL-Wawi an den Onlineshop sowie zum digitalen Produktpass nach der ESPR -- beide zeigen, dass eine sichere API-Schicht die Grundlage für neue Datenflüsse ist. Wie sich Token-Nutzung, Fehlerquoten und Anomalien im laufenden Betrieb sichtbar machen lassen, vertieft der Beitrag zur Observability von Schnittstellen.