OAuth 2.0
OAuth 2.0 ist ein offener Standard für Autorisierung, mit dem eine Anwendung im Namen eines Nutzers begrenzten Zugriff auf dessen Daten in einem anderen System erhält – ohne dass das Passwort weitergegeben wird. Statt Zugangsdaten preiszugeben, erteilt der Nutzer eine widerrufbare Freigabe, und die Anwendung erhält ein zeitlich begrenztes Zugriffstoken.
OAuth 2.0 ist ein offener Autorisierungsstandard, der es einer Anwendung erlaubt, im Namen eines Nutzers auf dessen Daten in einem anderen System zuzugreifen, ohne dass dabei das Passwort dieses Systems preisgegeben wird. Der Nutzer meldet sich direkt beim datenhaltenden Dienst an und erteilt der zugreifenden Anwendung eine ausdrücklich begrenzte, jederzeit widerrufbare Freigabe. Als Nachweis dieser Freigabe erhält die Anwendung ein sogenanntes Access Token – einen digitalen Schlüssel, der nur bestimmte Zugriffe für eine begrenzte Zeit erlaubt.
Der Kerngedanke von OAuth 2.0 ist die Trennung von Identität und Zugriffserlaubnis: Nicht die zugreifende App bekommt das Passwort in die Hand, sondern sie bekommt lediglich ein Token, das genau umreißt, was sie tun darf. Im ERP-Umfeld ist das die technische Grundlage dafür, dass etwa ein Onlineshop, ein Marktplatz-Connector oder eine Buchhaltungs-App gefahrlos auf das Warenwirtschaftssystem zugreifen kann, ohne dass irgendwo dauerhaft ein Klartext-Passwort hinterlegt werden muss.
Auf einen Blick
- Offener Standard für Autorisierung – regelt Zugriff, nicht die reine Anmeldung
- Apps greifen im Namen des Nutzers zu, ohne dessen Passwort zu kennen
- Zentrale Bausteine: Access Token, Refresh Token und eng gefasste Scopes
- Zugriffe sind zeitlich begrenzt und jederzeit widerrufbar
- Technische Basis für sichere API-Anbindungen von Shop, Marktplatz und Buchhaltung ans ERP
Wie OAuth 2.0 funktioniert
OAuth 2.0 beschreibt das Zusammenspiel mehrerer Rollen. Der Resource Owner ist der Nutzer, dem die Daten gehören. Der Resource Server ist das System, das diese Daten hält – im ERP-Kontext etwa die Warenwirtschaft mit ihren Aufträgen und Artikeln. Der Client ist die Anwendung, die zugreifen möchte, zum Beispiel ein Shop-Connector. Und der Authorization Server ist die Instanz, die die Freigabe des Nutzers entgegennimmt und daraufhin Tokens ausstellt.
Der typische Ablauf: Der Client leitet den Nutzer an den Authorization Server weiter. Dort meldet sich der Nutzer an und bestätigt, welche Zugriffe er erlauben will. Der Authorization Server stellt dem Client daraufhin ein Access Token aus. Mit diesem Token ruft der Client die geschützte Schnittstelle des Resource Servers auf, der das Token prüft und – falls gültig – die angeforderten Daten herausgibt. Der Client bekommt zu keinem Zeitpunkt das Passwort des Nutzers zu sehen.
Access Token, Refresh Token und Scopes
Ein Access Token ist bewusst kurzlebig, oft nur Minuten bis Stunden gültig, um den Schaden bei einem Diebstahl zu begrenzen. Damit die Anwendung nicht ständig eine neue Nutzerfreigabe braucht, gibt der Authorization Server häufig zusätzlich ein länger gültiges Refresh Token aus, mit dem der Client im Hintergrund ein frisches Access Token anfordert. Scopes wiederum umreißen den Umfang der Erlaubnis: Ein Scope kann etwa nur das Lesen von Bestellungen erlauben, nicht aber das Anlegen von Rechnungen. So lässt sich der Zugriff nach dem Prinzip der geringsten Rechte fein zuschneiden.
Grant Types: die Autorisierungsabläufe
OAuth 2.0 kennt mehrere Abläufe – „Grant Types“ genannt –, je nachdem, wer zugreift und wie vertrauenswürdig die Umgebung ist. Die Wahl des richtigen Ablaufs ist keine Formsache, sondern entscheidet über die Sicherheit der Anbindung.
Der Authorization Code Flow ist der Standard für Web- und Serveranwendungen, bei denen ein Mensch die Freigabe erteilt; moderne Umsetzungen sichern ihn zusätzlich mit dem PKCE-Verfahren ab. Der Client Credentials Flow kommt ohne beteiligten Nutzer aus und dient der reinen Server-zu-Server-Kommunikation – genau der Fall, wenn ein ERP nachts automatisiert Bestände mit einem Marktplatz abgleicht. Ältere Abläufe wie der Implicit Flow oder die direkte Passwortübergabe (Resource Owner Password Credentials) gelten heute als überholt und werden von Sicherheitsempfehlungen ausdrücklich abgeraten.
Warum OAuth 2.0 wichtig ist
Der größte Gewinn von OAuth 2.0 ist, dass Passwörter nicht mehr zwischen Systemen wandern. Früher musste man einer Fremd-App oft das eigene Passwort geben, damit sie in einem anderen Dienst arbeiten konnte – ein erhebliches Risiko, denn die App hätte damit vollen und dauerhaften Zugriff. Mit OAuth erhält die App nur ein begrenztes Token, das genau definierte Zugriffe für begrenzte Zeit erlaubt und sich jederzeit einzeln widerrufen lässt, ohne dass alle anderen Anbindungen betroffen sind.
Für Unternehmen bedeutet das mehr Kontrolle und weniger Angriffsfläche. Wird eine angebundene Anwendung kompromittiert, ist der Schaden auf deren eng gefasste Scopes und die Token-Laufzeit begrenzt. Zugleich ist OAuth 2.0 als weit verbreiteter Standard herstellerübergreifend nutzbar: Nahezu jede seriöse Cloud-Plattform, jeder Marktplatz und jedes moderne ERP unterstützt ihn, was die Integration verschiedener Systeme deutlich vereinfacht.
OAuth 2.0 im ERP-System
Ein ERP steht selten allein – rund um die Warenwirtschaft gruppieren sich Shopsystem, Marktplätze, Zahlungsdienstleister, Versanddienstleister und Buchhaltung. Jede dieser Anbindungen erfordert einen sicheren, maschinellen Zugriff über eine API, und OAuth 2.0 ist dafür heute der bevorzugte Autorisierungsmechanismus. Statt in jeder App ein ERP-Passwort zu hinterlegen, registriert man die App einmal beim Authorization Server des ERP und lässt sie fortan über Tokens arbeiten.
In der Praxis überwiegt im ERP-Kontext der Server-zu-Server-Fall: Zwei Systeme tauschen im Hintergrund Daten aus, ohne dass ein Mensch bei jedem Vorgang eine Freigabe klickt. Dafür eignet sich der Client Credentials Flow, bei dem sich die zugreifende Anwendung selbst mit einer Kennung und einem Geheimnis authentifiziert. Wichtig ist, dieses Geheimnis sicher zu verwahren, Scopes so eng wie möglich zu setzen und Tokens regelmäßig zu erneuern. Viele Cloud-ERP-Systeme stellen dafür eine dokumentierte REST-API samt OAuth-Endpunkten bereit; bei älteren oder On-Premise-Systemen übernimmt oft eine Middleware oder ein API-Gateway die Token-Verwaltung.
Abgrenzung: OAuth 2.0, OpenID Connect und API-Keys
OAuth 2.0 wird häufig mit Anmeldung verwechselt, regelt aber ausschließlich die Autorisierung – also die Frage, was eine Anwendung tun darf, nicht wer der Nutzer ist. Für die eigentliche Feststellung der Identität (Authentifizierung) wurde OpenID Connect entwickelt, das als dünne Schicht auf OAuth 2.0 aufsetzt und um ein sogenanntes ID Token ergänzt. Vereinfacht gilt: OpenID Connect klärt „Wer bist du?“, OAuth 2.0 klärt „Was darfst du?“. Beide bilden gemeinsam die Grundlage vieler Single-Sign-On-Lösungen.
Von einem einfachen API-Key unterscheidet sich OAuth 2.0 deutlich. Ein API-Key ist ein statischer, oft unbefristeter Schlüssel, der nicht zwischen Nutzern unterscheidet und bei Diebstahl vollen Dauerzugriff gewährt. OAuth-Tokens hingegen sind kurzlebig, an bestimmte Scopes gebunden und einzeln widerrufbar. Für einfache, interne Integrationen mag ein API-Key genügen; sobald aber im Namen einzelner Nutzer zugegriffen wird oder externe Anwendungen beteiligt sind, ist OAuth 2.0 die deutlich sicherere Wahl.
OAuth 2.0 und DSGVO im DACH-Raum
Weil OAuth 2.0 den Zugriff auf personenbezogene Daten – etwa Kunden- und Auftragsdaten im ERP – steuert, berührt es unmittelbar den Datenschutz. Die enge Fassung von Scopes zahlt direkt auf das Prinzip der Datenminimierung nach DSGVO ein: Eine App sollte nur die Datenbereiche freigeschaltet bekommen, die sie tatsächlich benötigt. Wird eine externe Anwendung angebunden, deren Anbieter Daten außerhalb der EU verarbeitet, sind zusätzlich die Vorgaben zur Auftragsverarbeitung und zum Drittlandtransfer zu beachten.
Für den Betrieb empfiehlt es sich, erteilte Freigaben und Tokens revisionssicher zu protokollieren, damit im Prüfungsfall nachvollziehbar ist, welche Anwendung wann auf welche Daten zugegriffen hat. Ebenso sollte es ein geregeltes Verfahren geben, um Tokens beim Ausscheiden eines Dienstleisters oder bei Verdacht auf Missbrauch sofort zu widerrufen. So wird OAuth 2.0 nicht nur zum Sicherheits-, sondern auch zum Compliance-Baustein einer sauberen Systemintegration.
Praxisbeispiel
Beispiel: Marktplatz-Anbindung eines Onlinehändlers
Ein mittelständischer Onlinehändler verkauft neben dem eigenen Shop auch über einen großen Marktplatz. Ein Connector soll Bestände und Bestellungen automatisch zwischen Marktplatz und ERP abgleichen. Früher hätte man dafür das ERP-Passwort im Connector hinterlegt – mit dem Risiko, dass ein kompromittierter Connector vollen Zugriff auf die gesamte Warenwirtschaft gehabt hätte.
Mit OAuth 2.0 läuft es anders: Der Connector wird einmal beim ERP registriert und erhält eine Client-Kennung samt Geheimnis. Über den Client Credentials Flow holt er sich nachts ein kurzlebiges Access Token mit eng gefassten Scopes – nur Lesen von Beständen und Anlegen von Bestellungen, sonst nichts. Fällt auf, dass der Connector kompromittiert wurde, widerruft die IT dessen Zugriff mit einem einzigen Handgriff, ohne dass Passwörter geändert oder andere Anbindungen angefasst werden müssen.
Häufige Fragen
Passende ERP-Systeme
Passende Leistungen
Quellen
Fragen zu OAuth 2.0 in deinem ERP-Projekt?
Wir beraten herstellerunabhängig – und setzen es auf Wunsch selbst um.