OAuth

OAuth ist ein offenes Autorisierungsprotokoll, mit dem eine Anwendung im Namen eines Nutzers oder eines Systems begrenzt auf geschützte Ressourcen einer anderen Anwendung zugreifen darf, ohne dessen Passwort zu kennen. Statt Zugangsdaten weiterzureichen, erhält der Client ein zeitlich befristetes Access Token mit klar definiertem Umfang (Scope). Die aktuelle Fassung ist OAuth 2.0 (RFC 6749); OAuth 2.1 fasst das Protokoll mit den seither etablierten Sicherheitspraktiken zusammen.

Was OAuth ist und welches Problem es löst

Vor OAuth war der übliche Weg, einer Drittanwendung Zugriff auf ein Konto zu geben, das Weitergeben von Benutzername und Passwort. Die Drittanwendung bekam damit vollen Zugriff, konnte das Passwort speichern und ließ sich nicht gezielt wieder aussperren. OAuth ersetzt dieses Muster durch eine Delegation: Der Nutzer stimmt beim Dienst, der die Daten hält, einem konkreten Zugriff zu, und die Drittanwendung erhält dafür ein Token.

Das Token ist an einen Umfang gebunden, etwa „Bestellungen lesen", und läuft nach kurzer Zeit ab. Der Nutzer kann die Freigabe jederzeit widerrufen, ohne sein Passwort zu ändern. Für Betreiber von Shops, ERP-Systemen und Kundenportalen ist OAuth deshalb die Standardgrundlage, sobald externe Anwendungen, Apps oder KI-Agenten an eine REST-API angebunden werden.

Wichtig für die Einordnung: OAuth regelt die Autorisierung, also die Frage „Was darf dieser Client?". Es beantwortet nicht die Frage „Wer ist dieser Nutzer?". Dafür gibt es OpenID Connect, das auf OAuth aufsetzt. Mehr dazu weiter unten.

Die vier Rollen im OAuth-Modell

RFC 6749 definiert vier Rollen, die in jedem OAuth-Ablauf vorkommen. Wer sie sauber auseinanderhält, versteht auch die Grant-Typen und die Sicherheitsregeln ohne Mühe.

Authorization Server und Resource Server können dieselbe Software sein, müssen es aber nicht. In größeren Architekturen übernimmt ein zentraler Identity Provider die Tokenausgabe, während Dutzende Microservices als Resource Server die Tokens nur prüfen.

Access Token, Refresh Token und Scope

Das Access Token ist der Schlüssel, den der Client bei jedem Request im HTTP-Header Authorization: Bearer … mitschickt. Es ist bewusst kurzlebig. Das Refresh Token dient ausschließlich dazu, beim Authorization Server ein neues Access Token zu holen, ohne den Nutzer erneut einzubeziehen. Der Scope beschreibt, welche Rechte das Token umfasst. Hier gilt das Least-Privilege-Prinzip: Ein Client sollte nur die Scopes anfordern, die er wirklich braucht.

OAuth 2.0 und OAuth 2.1: Was sich ändert

OAuth 2.0 wurde 2012 als RFC 6749 veröffentlicht. In den Jahren danach kamen zahlreiche Ergänzungen hinzu, darunter PKCE (RFC 7636), die Best-Practice-Empfehlungen für native Apps (RFC 8252) und die Security Best Current Practice. Wer das Protokoll korrekt umsetzen wollte, musste diese Dokumente zusammenlesen.

OAuth 2.1 ist ein IETF-Entwurf (draft-ietf-oauth-v2-1), der genau diese Konsolidierung leistet. Er führt keine neuen Konzepte ein, sondern streicht unsichere Varianten und macht bewährte Schutzmaßnahmen verpflichtend. Die wichtigsten Änderungen gegenüber OAuth 2.0:

• PKCE ist für alle Clients im Authorization Code Flow Pflicht, nicht nur für mobile oder öffentliche Clients.
• Redirect-URIs müssen per exaktem Stringvergleich geprüft werden; Teil- oder Pattern-Matching ist nicht mehr erlaubt.
• Der Implicit Grant (response_type=token) ist gestrichen.
• Der Resource Owner Password Credentials Grant ist gestrichen.
• Bearer Tokens dürfen nicht mehr als URL-Query-Parameter übertragen werden.
• Refresh Tokens für öffentliche Clients müssen entweder sender-gebunden sein oder bei jeder Nutzung rotiert werden.

Für die Praxis heißt das: Wer heute ein OAuth-System neu baut oder eine Integration umsetzt, sollte direkt nach den Regeln von OAuth 2.1 arbeiten. Jeder moderne Authorization Server unterstützt sie, und Protokolle wie MCP setzen sie bereits voraus.

Grant-Typen: Welche Abläufe es gibt

Ein Grant beschreibt, auf welchem Weg der Client an sein Access Token kommt. OAuth 2.1 kennt im Kern zwei Abläufe für den Alltag, dazu den Refresh-Token-Grant und Erweiterungen wie den Device Authorization Grant für Geräte ohne Browser.

Authorization Code Flow mit PKCE

Dies ist der Standardablauf, sobald ein Mensch beteiligt ist. Der Client leitet den Nutzer per Browser an den Authorization Server weiter. Dort meldet sich der Nutzer an und bestätigt den Zugriff. Der Authorization Server schickt den Browser mit einem kurzlebigen Authorization Code an die registrierte Redirect-URI zurück. Der Client tauscht diesen Code anschließend über einen direkten Server-Aufruf gegen das Access Token ein.

PKCE (Proof Key for Code Exchange, gesprochen „Pixie") schützt den Austausch des Codes. Der Client erzeugt vor dem Start einen zufälligen code_verifier, bildet daraus einen SHA-256-Hash (code_challenge, Methode S256) und sendet nur den Hash mit der Autorisierungsanfrage. Beim Token-Request legt er den ursprünglichen Verifier vor. Ein Angreifer, der den Authorization Code abfängt, kann ihn ohne den Verifier nicht einlösen.

GET /authorize?response_type=code
  &client_id=shop-frontend
  &redirect_uri=https://shop.example/callback
  &scope=orders:read
  &state=af0ifjsldkj
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256

POST /token
grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https://shop.example/callback
&client_id=shop-frontend
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

Der state-Parameter bindet die Antwort an die ursprüngliche Anfrage und schützt vor Cross-Site-Request-Forgery. Der Client muss ihn beim Rücksprung prüfen und Antworten mit abweichendem Wert verwerfen.

Client Credentials Grant

Wenn kein Nutzer beteiligt ist, etwa bei einem nächtlichen Abgleich zwischen ERP und Shop, authentifiziert sich der Client mit eigener ID und eigenem Secret direkt beim Token-Endpunkt. Das ausgestellte Token repräsentiert dann die Anwendung selbst, nicht eine Person. Dieser Grant eignet sich ausschließlich für vertrauliche Clients, also Server, die ein Secret sicher verwahren können. In einer Single-Page-App oder einer Mobile-App hat ein Client Secret nichts verloren.

POST /token
Authorization: Basic base64(client_id:client_secret)
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&scope=products:write

Gestrichene Grants: Implicit und Password

Der Implicit Grant lieferte das Access Token direkt im URL-Fragment an den Browser zurück. Das Token landete damit in Browser-History, Referrer-Headern und Logs. Da Single-Page-Apps heute den Authorization Code Flow mit PKCE nutzen können, gibt es keinen Grund mehr für diesen Ablauf.

Der Password Grant ließ den Client Benutzername und Passwort einsammeln und gegen ein Token tauschen. Das untergräbt den Grundgedanken von OAuth, denn der Client sieht das Passwort. Außerdem funktionieren Multi-Faktor-Authentifizierung und Single Sign-on in diesem Modell nicht. OAuth 2.1 hat beide Grants deshalb entfernt. Bestehende Systeme, die sie noch verwenden, sollten migriert werden.

Öffentliche und vertrauliche Clients

OAuth unterscheidet Clients danach, ob sie ein Secret sicher aufbewahren können. Ein Backend-Dienst ist ein vertraulicher Client. Eine Browser-App, eine Mobile-App oder ein CLI-Tool auf dem Rechner eines Nutzers ist ein öffentlicher Client. Für öffentliche Clients gelten strengere Regeln: PKCE ist zwingend, Refresh Tokens müssen rotiert werden, und Redirect-URIs sollten auf localhost oder HTTPS beschränkt sein.

OAuth vs. OpenID Connect: Autorisierung und Authentifizierung

OAuth und OpenID Connect (OIDC) werden häufig verwechselt, weil sie denselben Ablauf nutzen. Der Unterschied liegt im Zweck. OAuth liefert ein Access Token, das beschreibt, worauf ein Client zugreifen darf. Es sagt nichts Verbindliches darüber aus, wer sich angemeldet hat. Ein Access Token ist für den Resource Server gedacht und für den Client in der Regel undurchsichtig.

OpenID Connect ist eine Identitätsschicht über OAuth 2.0. Sie ergänzt ein ID Token, ein signiertes JSON Web Token mit Angaben zur Identität des Nutzers (Subject, Aussteller, Ablaufzeit, optional Name und E-Mail). Das ID Token ist für den Client bestimmt und beantwortet die Frage „Wer ist das?". Dazu kommen ein standardisierter UserInfo-Endpunkt und die Discovery über /.well-known/openid-configuration.

Als Faustregel: Wenn deine Anwendung einen Nutzer anmelden soll, brauchst du OpenID Connect. Wenn deine Anwendung im Namen eines Nutzers oder Systems auf eine API zugreifen soll, brauchst du OAuth. In der Praxis laufen beide meist in einem Request zusammen, indem der Scope openid zusätzlich angefordert wird.

Realbeispiel: „Mit Google anmelden" und die Shopware-Admin-API

Beim Button „Mit Google anmelden" ist Google der Authorization Server und zugleich OpenID Provider. Dein Shop ist der Client. Der Nutzer wird zu Google weitergeleitet, meldet sich dort an und sieht, welche Daten der Shop anfordert, beispielsweise E-Mail und Profilname. Nach der Zustimmung tauscht der Shop den Authorization Code serverseitig gegen ID Token und Access Token. Das Passwort des Google-Kontos sieht der Shop zu keinem Zeitpunkt.

Ein zweites Beispiel aus dem E-Commerce ist die Admin-API von Shopware 6. Sie nutzt OAuth 2.0 für alle Zugriffe. Für System-Integrationen legst du in der Administration unter „Einstellungen, System, Integrationen" eine Integration an. Shopware erzeugt einen Access Key ID und einen Secret Access Key, die als client_id und client_secret im Client-Credentials-Grant verwendet werden. Der Token-Endpunkt ist /api/oauth/token; das Access Token ist eine Stunde gültig.

POST /api/oauth/token
Content-Type: application/json

{
  "grant_type": "client_credentials",
  "client_id": "SWIAXXXXXXXXXXXXXXXXXXXXXX",
  "client_secret": "…"
}

Die Shopware-Administration selbst meldet Benutzer dagegen mit Benutzername und Passwort am selben Token-Endpunkt an, also über den Password Grant mit Refresh Token. Für neue Integrationen von außen ist dieser Weg nicht vorgesehen; hier gehört die Integration mit Client Credentials und auf die nötigen Rechte beschränkter Rolle zum Standard.

OAuth bei KI-Agenten und MCP

Mit KI-Agenten bekommt OAuth eine neue Rolle. Ein Agent, der im Auftrag eines Mitarbeiters Bestellungen prüft oder CRM-Daten liest, braucht genau das, was OAuth bietet: delegierte, begrenzte und widerrufbare Zugriffsrechte. Das Model Context Protocol (MCP) hat OAuth deshalb fest in seine Spezifikation aufgenommen.

Die MCP-Spezifikation definiert OAuth 2.1 als Autorisierungsrahmen für HTTP-basierte MCP-Server. Ein geschützter MCP-Server ist dabei ein OAuth-2.1-Resource-Server, der MCP-Client ein OAuth-2.1-Client. Authorization Server müssen OAuth 2.1 umsetzen, MCP-Server müssen Protected Resource Metadata (RFC 9728) bereitstellen, und Clients müssen PKCE mit S256 sowie den resource-Parameter nach RFC 8707 verwenden, damit Tokens an den jeweiligen Server gebunden sind. Für STDIO-Transporte gilt die Spezifikation nicht; dort kommen Zugangsdaten aus der Umgebung.

Die Spezifikationsversion vom 28.07.2026 hat die Client-Registrierung umgebaut. Dynamic Client Registration nach RFC 7591 gilt als deprecated und bleibt nur aus Kompatibilitätsgründen erhalten. An ihre Stelle treten Client ID Metadata Documents: Der Client verwendet eine HTTPS-URL als client_id, hinter der ein JSON-Dokument mit Name und Redirect-URIs liegt. Der Authorization Server lädt dieses Dokument bei Bedarf. Das löst das typische MCP-Problem, dass Client und Server sich vorher nicht kennen.

Zusätzlich verlangt dieselbe Version eine Prüfung des iss-Parameters in der Autorisierungsantwort nach RFC 9207. Der Client merkt sich vor der Weiterleitung den Issuer des Authorization Servers und vergleicht ihn beim Rücksprung. Das verhindert Mix-up-Angriffe, bei denen ein kompromittierter Authorization Server einen Code eines anderen Servers abgreift. Wie das in der Praxis zusammenspielt, erklärt unser Beitrag MCP-Server erklärt.

Die Anbieter ziehen nach. HubSpot hat seinen Remote-MCP-Server am 13.04.2026 allgemein verfügbar gemacht und verlangt für jede Verbindung OAuth 2.1 mit PKCE. Für Agenturen und Entwicklerteams bedeutet das: Wer KI-Agenten an Shop, ERP oder CRM anbindet, kommt an einer sauberen OAuth-2.1-Implementierung nicht vorbei.

Typische Fehler in der Umsetzung

Die meisten Sicherheitsprobleme mit OAuth entstehen nicht im Protokoll, sondern in der Implementierung. Diese Punkte solltest du bei jeder Integration prüfen:

• Redirect-URIs werden nur per Präfix oder Wildcard geprüft. Ein Angreifer kann dann Codes auf eine eigene Domain umleiten.
• Access Tokens werden in URLs, Logs oder im localStorage des Browsers abgelegt, wo sie per XSS auslesbar sind.
• Der Resource Server prüft die Audience des Tokens nicht und akzeptiert Tokens, die für einen anderen Dienst ausgestellt wurden.
• Scopes werden pauschal auf „alles" gesetzt, statt pro Integration nur die nötigen Rechte zu vergeben.
• Client Secrets landen in Frontend-Code, Mobile-Apps oder öffentlichen Repositories.
• Langlebige Tokens ohne Rotation, sodass ein einmal entwendetes Token dauerhaft gültig bleibt.

Ein bewährter Weg ist, nicht selbst einen Authorization Server zu schreiben, sondern eine geprüfte Komponente wie Keycloak, Microsoft Entra ID oder einen vergleichbaren Identity Provider einzusetzen und die eigenen Services nur als Resource Server zu betreiben.

Häufige Fragen zu OAuth

Ist OAuth ein Login-Verfahren? Nein. OAuth regelt die Autorisierung, also welche Rechte ein Client bekommt. Für die Anmeldung eines Nutzers wird OpenID Connect verwendet, das auf OAuth 2.0 aufbaut und ein ID Token mit Identitätsangaben ergänzt.

Brauche ich PKCE auch für Server-Anwendungen? Ja. OAuth 2.1 schreibt PKCE für alle Clients im Authorization Code Flow vor, unabhängig davon, ob sie ein Client Secret besitzen. PKCE schützt gegen das Abfangen und Einschleusen von Authorization Codes und kostet in der Umsetzung nur wenige Zeilen.

Was ist der Unterschied zwischen Access Token und Refresh Token? Das Access Token wird bei jedem API-Aufruf mitgeschickt und ist kurzlebig. Das Refresh Token dient nur dazu, beim Authorization Server ein neues Access Token zu holen. Es wird nie an den Resource Server gesendet und muss besonders geschützt werden.

Welche OAuth-Version brauche ich für MCP-Server? Die MCP-Spezifikation setzt OAuth 2.1 voraus, inklusive PKCE mit S256, Protected Resource Metadata nach RFC 9728 und dem resource-Parameter nach RFC 8707. Seit der Version vom 28.07.2026 sollen Clients außerdem Client ID Metadata Documents unterstützen und den iss-Parameter nach RFC 9207 prüfen.