Was ist OAuth?

Sichere Autorisierung ohne Weitergabe von Passwörtern. Das OAuth-Protokoll bildet das Fundament für modernen API-Schutz und föderierte Identitäten.

Die fortschreitende Vernetzung digitaler Dienste und die weitverbreitete Nutzung von Programmierschnittstellen haben die Verwaltung von Zugriffsrechten in der Informationstechnik grundlegend verändert. In der Frühphase des World Wide Webs standen Softwareentwickler vor einem erheblichen strukturellen Problem, wenn eine Anwendung im Namen eines Benutzers auf Daten einer anderen Plattform zugreifen sollte. Ein klassisches Szenario war der Import von Kontaktdaten: Eine neue Anwendung verlangte vom Benutzer die Eingabe der vollständigen Anmeldedaten des primären E-Mail-Anbieters, um das Adressbuch auszulesen.

Diese Praxis erzeugte immense Sicherheitsrisiken, da der Benutzer der Drittanbieter-Anwendung unkontrollierten Vollzugriff auf sein gesamtes Konto gewähren musste. Das geheime Passwort wurde auf fremden Servern gespeichert, und der Benutzer hatte keine Möglichkeit, die Rechte selektiv einzuschränken oder separat zu widerrufen.

Open Authorization, universell als OAuth abgekürzt, löst dieses Sicherheitsdilemma vollständig auf. Es handelt sich um ein offenes Standardprotokoll für die sichere, tokenbasierte Autorisierung und Zugriffdelegierung. OAuth ermöglicht es einer Anwendung, im Namen eines Benutzers einen limitierten Zugriff auf geschützte Ressourcen zu erhalten, ohne dass der Benutzer jemals seine geheimen Anmeldedaten an diese Anwendung weitergeben muss.

Ein anschauliches und in der Fachwelt oft genutztes Beispiel für dieses Prinzip ist der Hotelschlüssel oder der Valet-Schlüssel eines Autos. Wenn ein Autobesitzer sein Fahrzeug an einen Parkdienst übergibt, händigt er nicht den Generalschlüssel aus, mit dem sich auch das Handschuhfach öffnen oder der Tank entleeren lässt. Er übergibt einen speziellen Valet-Schlüssel, der dem Mitarbeiter ausschließlich das Starten und Parken des Fahrzeugs für eine begrenzte Distanz erlaubt. Genau diese Funktion übernimmt das OAuth-Protokoll in der digitalen Welt: Es stellt eine begrenzte, temporäre Eintrittskarte aus, anstatt den Hauptschlüssel zu kopieren.

Die historische Entwicklung und der aktuelle Standard OAuth 2.1

Das Protokoll entstand im Jahr 2007 aus einer Initiative von Entwicklern bei Twitter und Google, da bestehende proprietäre Protokolle den Anforderungen an ein offenes Websystem nicht genügten. Das ursprüngliche OAuth 1.0 wies jedoch komplexe kryptografische Anforderungen auf, da jede einzelne Anfrage digital signiert werden musste. Dies erschwerte die Implementierung in Webanwendungen und führte zu Interoperabilitätsproblemen.

Im Jahr 2012 folgte die Veröffentlichung von OAuth 2.0, spezifiziert im Standard RFC 6749 der Internet Engineering Task Force. OAuth 2.0 ersetzte die komplexen Signaturverfahren durch den flächendeckenden Einsatz von Transport Layer Security zur Verschlüsselung des Datenverkehrs und führte verschiedene Autorisierungsabläufe für unterschiedliche Anwendungstypen ein.

Im Jahr 2026 ist die technologische Entwicklung bei der Konsolidierung des Standards im Rahmen von OAuth 2.1 angekommen. Diese neue Iteration erfindet das Protokoll nicht neu, sondern fasst die Best Current Practices der vergangenen Jahre in einem einzigen, bereinigten Standard zusammen. Sie dekretiert deutlich erhöhte Sicherheitsanforderungen. Hierzu gehören die verpflichtende Nutzung von Proof Key for Code Exchange für alle Clients und die endgültige Deprecierung unsicherer Abläufe, die sich in der Vergangenheit als anfällig für Angriffe erwiesen haben. Die fortlaufenden Spezifikationen und aktuellen Entwürfe der IETF-Arbeitsgruppe können auf dem offiziellen OAuth-Portal verfolgt werden.

Die vier Rollen im OAuth-Gefüge

Die gesamte Architektur eines OAuth-Prozesses stützt sich auf die exakte Definition und das Zusammenspiel von vier logischen Rollen. Jede Transaktion erfordert die Koordination dieser Entitäten, um eine sichere Zugriffsgewährung zu realisieren.

1. Die erste Rolle ist der Resource Owner. Hierbei handelt es sich in der Regel um den menschlichen Endbenutzer, der die Kontrolle über die geschützten Daten besitzt und befugt ist, den Zugriff auf diese Daten an eine Software zu delegieren.
2. Die zweite Rolle ist der Client. Dies ist die Softwareanwendung, die im Namen des Resource Owners Zugriff auf die geschützten Ressourcen anfordert. Der Client kann eine mobile App auf einem Smartphone, eine Single-Page-Webanwendung im Browser oder ein autonomer Server-Dienst im Hintergrund des Rechenzentrums sein.
3. Die dritte Rolle ist der Resource Server. Auf diesem System befinden sich die geschützten Daten des Benutzers, beispielsweise E-Mail-Postfächer, Bilderspeicher oder Profildaten. Der Resource Server nimmt API-Anfragen entgegen und ist in der Lage, Zugriffs-Token zu akzeptieren und zu verifizieren, um die angeforderten Ressourcen im Erfolgsfall auszuliefern.
4. Die vierte Rolle ist der Authorization Server. Dieses System bildet das administrative Gehirn des Prozesses. Es authentifiziert den Resource Owner, holt dessen explizite Zustimmung ein und stellt nach erfolgreicher Verifizierung die kryptografischen Zugriffs-Token an den Client aus. In modernen Enterprise-Umgebungen wird diese Rolle oft von zentralen Identitätsdiensten übernommen. Der Autorisierungsserver und der Ressourcenserver können als logische Einheit auf demselben System laufen oder als physisch getrennte Infrastrukturen operieren.

Die Funktionsweise von Token und die Bedeutung von Scopes

Der Kern von OAuth basiert auf der vollständigen Ersetzung von Passwörtern durch temporäre, limitierte Zeichenketten, die als Token bezeichnet werden. Man unterscheidet im operativen Ablauf primär zwei Arten von Token mit unterschiedlichen Aufgaben und Lebenszyklen.

Das wichtigste Werkzeug ist der Access Token. Er fungiert wie eine digitale Eintrittskarte, die der Client bei jeder API-Anfrage an den Resource Server im HTTP-Header mitsenden muss. Der Access Token hat eine begrenzte Gültigkeit, die je nach Sicherheitsrichtlinie des Unternehmens oft nur wenige Minuten oder Stunden beträgt. Technisch wird dieser Token in modernen Infrastrukturen häufig als JSON Web Token realisiert, spezifiziert nach RFC 7519. Ein JWT enthält die Autorisierungsdaten, den Aussteller und die Gültigkeitsdauer im Klartext und wird vom Autorisierungsserver digital signiert, sodass der Ressourcenserver die Echtheit ohne erneute Datenbankabfrage überprüfen kann.

Ergänzend dazu existiert der Refresh Token. Da Access Token aus Sicherheitsgründen schnell ablaufen, nutzt der Client den deutlich langlebigeren Refresh Token, um beim Authorization Server einen neuen Access Token anzufordern, ohne dass der Benutzer sich erneut manuell mit seinem Passwort anmelden muss. Der Refresh Token wird unter strengen Sicherheitsauflagen gespeichert und verbleibt ausschließlich im direkten Kommunikationskanal zwischen dem Client und dem Autorisierungsserver.

Die feingranulare Steuerung der Rechte innerhalb dieser Token erfolgt über sogenannte Scopes. Ein Scope definiert eine spezifische Berechtigung, die der Client anfordert. Beispielsweise kann eine Anwendung den Scope für den reinen Lesezugriff auf den Kalender anfordern, während der Schreibzugriff blockiert bleibt. Der Benutzer sieht diese Scopes während des Autorisierungsdialogs auf seinem Bildschirm und entscheidet präzise, welche Teilrechte er der Anwendung gewährt.

Der schrittweise Ablauf des Authorization Code Flow mit PKCE

Für Anwendungen, die auf einem geschützten Webserver laufen oder als native Apps auf Mobilgeräten ausgeführt werden, ist der Authorization Code Flow in Kombination mit Proof Key for Code Exchange der verbindliche Sicherheitsstandard. Dieser Prozess trennt den Erhalt der Autorisierung strikt vom Erhalt der eigentlichen Token. Der Ablauf folgt einer exakt definierten Sequenz:

Erstens sendet der Client eine Autorisierungsanfrage und leitet den Webbrowser des Benutzers zum Authorization Server um. In dieser Anfrage sind die Client-ID, die gewünschten Scopes, eine vordefinierte Weiterleitungs-URL und ein kryptografischer Code-Challenge enthalten, den der Client im Rahmen des PKCE-Verfahrens lokal generiert hat.

Zweitens erfolgt die Authentifizierung und der Konsens. Der Benutzer meldet sich direkt am Authorization Server mit seinen primären Zugangsdaten an. Der Client sieht diese Eingabe nicht. Anschließend präsentiert der Server dem Benutzer die angeforderten Scopes. Der Benutzer bestätigt den Zugriff explizit.

Drittens stellt der Server den Autorisierungscode aus. Nach der Zustimmung leitet der Authorization Server den Webbrowser zurück zum Client. Als Parameter in der Weiterleitungs-URL wird ein kurzlebiger, einmalig verwendbarer Autorisierungscode übermittelt.

Viertens findet der Token-Austausch statt. Der Client nimmt den Autorisierungscode entgegen und sendet ihn direkt über einen sicheren Server-zu-Server-Kanal zurück an den Autorisierungsserver. Bei dieser Anfrage muss der Client das kryptografische Gegenstück zum ursprünglichen Code-Challenge mitsenden, den sogenannten Code Verifier.

Fünftens erfolgt die Token-Ausstellung. Der Autorisierungsserver überprüft den empfangenen Code und verifiziert mathematisch, dass der Code-Verifier zum ursprünglichen Challenge passt. Dies ist der Kern des PKCE-Schutzes, spezifiziert in RFC 7636 unter https://datatracker.ietf.org/doc/html/rfc7636. Dadurch wird verhindert, dass Angreifer, die den Autorisierungscode auf dem Transportweg im Browser abfangen, diesen missbrauchen können, da ihnen der geheime Verifier fehlt. Bei erfolgreicher Prüfung stellt der Server den Access Token und den Refresh Token aus.

Sechstens erfolgt der eigentliche Ressourcen-Zugriff. Der Client nutzt den erhaltenen Access Token, um Daten vom Resource Server abzufragen. Der Resource Server prüft die Signatur des Tokens und liefert die Daten aus.

Bereinigung der Abläufe unter der Spezifikation OAuth 2.1

In den Spezifikationen von OAuth 2.0 existierten verschiedene Abläufe, die für spezifische technologische Einschränkungen der damaligen Zeit konzipiert waren, sich jedoch im Laufe der Jahre als strukturelle Sicherheitsrisiken herauskristallisiert haben. Der aktuelle Standard von OAuth 2.1 zieht hieraus Konsequenzen und dekretiert eine Bereinigung der erlaubten Verfahren, wie in den offiziellen Entwürfen der IETF dokumentiert ist.

Ein prominentes Beispiel für eine vollständige Deprecierung ist der Implicit Grant. Dieser Ablauf wurde ursprünglich für Single-Page-Anwendungen im Browser entwickelt, um den Token direkt ohne den Zwischenschritt eines Autorisierungscodes zu übertragen. Da der Access Token hierbei direkt in der URL des Browsers sichtbar war, konnte er über Browser-Historien, Proxy-Logs oder bösartige Skripte leicht entwendet werden. Unter OAuth 2.1 ist dieser Ablauf vollständig verboten. Single-Page-Anwendungen müssen stattdessen den regulären Authorization Code Flow in Kombination mit PKCE nutzen.

Ebenfalls vollständig eliminiert wurde der Resource Owner Password Credentials Grant. Bei diesem Ablauf übergab der Benutzer sein Passwort direkt an den Client, welcher es dann an den Autorisierungsserver weiterleitete. Dies widersprach dem Grundgedanken von OAuth, Passwörter niemals mit Drittanwendungen zu teilen, und öffnete Angriffsvektoren für den Missbrauch von Zugangsdaten. Erlaubt sind neben dem Authorization Code Flow im Wesentlichen nur noch der Client Credentials Grant für die reine Maschine-zu-Maschine-Kommunikation ohne menschlichen Benutzer sowie der Device Authorization Grant für Geräte ohne Tastatur oder Bildschirm, wie etwa intelligente Fernseher oder IoT-Komponenten.

Ein systematischer Vergleich: OAuth vs. OIDC vs. SAML

In der Praxis des betrieblichen Identitätsmanagements kommt es regelmäßig zu Begriffsverwirrungen zwischen verschiedenen offenen Standards. OAuth wird fälschlicherweise oft als Methode zur Benutzeranmeldung bezeichnet. Um die informationstechnische Sicherheit zu wahren, ist eine präzise Abgrenzung zu OpenID Connect und der Security Assertion Markup Language erforderlich.

Kriterium	OAuth 2.0 / 2.1	OpenID Connect (OIDC)	Security Assertion Markup Language (SAML)
Primärer Fokus	Autorisierung (Zugriffsdelegierung)	Authentifizierung (Identitätsnachweis)	Föderierte Identität (SSO im Enterprise)
Zentrales Token	Access Token	ID Token (zwingend ein signiertes JWT)	SAML Assertion (XML-Dokument)
Datenformat	JSON / HTTP-Header	JSON / Web-Standards	XML / SOAP-Schnittstellen
Analogie	Eintrittskarte für einen Raum	Personalausweis zur Bestätigung der Identität	Firmenausweis für den Zugang zu allen Gebäuden
Einsatzbereich	API-Absicherung, Cloud-Dienste, Mobile Apps	Single Sign-On für moderne Webanwendungen	Legacy-Systeme, Konzern-Infrastrukturen

OpenID Connect baut direkt als Identitätsschicht auf dem OAuth-Protokoll auf. Die Spezifikationen dieser Erweiterung werden von der OpenID Foundation gepflegt. Während das reine OAuth dem Client lediglich ein unleserliches Token übergibt, das den Zugriff erlaubt, liefert OIDC über ein zusätzliches ID-Token konkrete, standardisierte Benutzerinformationen wie den Namen, die E-Mail-Adresse und den Zeitpunkt der Anmeldung. SAML hingegen ist ein älterer, XML-basierter Standard, der in klassischen On-Premises-Konzernstrukturen für das Single Sign-On genutzt wird, in modernen Cloud-Architekturen aufgrund seiner Komplexität jedoch zunehmend durch die Kombination aus OAuth und OIDC abgelöst wird.

Bekannte Angriffsvektoren und deren technologische Mitigierung

Obwohl das OAuth-Protokoll kryptografisch sicher konzipiert ist, führen Fehler bei der Software-Implementierung oder fehlerhafte Konfigurationen der Server regelmäßig zu kritischen Sicherheitslücken. IT-Sicherheitsverantwortliche müssen die bekannten Angriffsvektoren kontinuierlich überwachen und organisatorisch unterbinden.

Ein erhebliches Risiko sind ungenau konfigurierte Weiterleitungs-URLs auf dem Autorisierungsserver, sogenannte Open Redirectors. Wenn der Server nach der erfolgreichen Autorisierung des Benutzers den Autorisierungscode an eine beliebige, vom Client dynamisch übermittelte URL sendet, können Angreifer den Datenstrom manipulieren. Sie leiten den Code auf ein eigenes System um, fangen ihn dort ab und tauschen ihn gegen valide Token aus. Moderne Richtlinien fordern daher einen exakten, binären Abgleich der Ziel-URL mit einer vordefinierten, statischen Whitelist im Autorisierungsserver.

Ein weiterer Angriffsvektor ist das Token-Leaking durch Cross-Site-Scripting. Werden Access Token im ungeschützten lokalen Speicher des Webbrowsers abgelegt, können sie bei erfolgreichen XSS-Angriffen von injiziertem Schadcode ausgelesen werden. Das IT-Management muss über restriktive Content Security Policies und den Einsatz sicherer Cookie-Attribute wie HttpOnly dafür sorgen, dass Token vor dem Zugriff durch bösartige Skripte geschützt sind. Für die Abwehr von Cross-Site-Request-Forgery-Angriffen implementiert das Protokoll zudem den State-Parameter. Dieser fungiert als einmaliges, kryptografisches Kennzeichen, mit dem der Client verifizieren kann, dass die Antwort des Autorisierungsservers tatsächlich zu einer von ihm selbst initiierten Anfrage gehört.

Regulatorische Compliance und die Anforderungen des IT-Grundschutzes

Die Implementierung standardisierter Autorisierungsprotokolle wie OAuth ist eine wesentliche Bedingung für die Erfüllung gesetzlicher Vorgaben im Bereich des Datenschutzes und der Informationssicherheit. Unter der europäischen Datenschutz-Grundverordnung müssen Unternehmen nachweisbar dokumentieren, dass der Zugriff auf personenbezogene Daten streng reglementiert ist und dem Prinzip der Zweckbindung sowie des Least Privilege entspricht. OAuth erlaubt über das integrierte Scope-System genau diese feingranulare Vergabe von Rechten, wodurch Überprivilegierungen systematisch verhindert werden können.

Das deutsche Bundesamt für Sicherheit in der Informationstechnik definiert im IT-Grundschutz-Kompendium klare Anforderungen für das Identitäts- und Berechtigungsmanagement, nachlesbar auf dem offiziellen Portal. In den Bausteinen der Reihe ORP (Organisation und Personal) und SYS (IT-Systeme) wird gefordert, dass Zugriffe auf Webschnittstellen und interne Ressourcen über sichere, standardisierte Verfahren authentifiziert und autorisiert werden müssen. Die lückenlose Protokollierung aller Token-Ausstellungen auf dem Authorization Server liefert zudem die notwendigen, revisionssicheren Nachweise bei offiziellen Compliance-Audits oder im Rahmen von Sicherheitsüberprüfungen nach der europäischen NIS2-Richtlinie.

Fazit

OAuth hat sich von einer pragmatischen Entwicklerlösung zum unumstößlichen Industriestandard für die Absicherung moderner API-Infrastrukturen und Cloud-Ökosysteme entwickelt. Durch die konsequente Trennung von Authentifizierung und Autorisierung eliminiert das Protokoll die Notwendigkeit der riskanten Passwortweitergabe und minimiert die Angriffsfläche im Identitätsraum erheblich. Für ein zukunftsorientiertes IT-Management ist die tiefe Integration von OAuth-Strukturen, die konsequente Durchsetzung der harten Sicherheitsrichtlinien von OAuth 2.1 und das fortlaufende Management der Token-Lebenszyklen eine fundamentale Kernaufgabe, um die informationelle Souveränität des Unternehmens in einer dezentralen digitalen Wirtschaft dauerhaft zu sichern.