Glossareintrag
Wir denken. KI tippt mit.
OAuth (gesprochen „O-Auth“, kurz für Open Authorization) ist ein offener Standard, mit dem Nutzer einer Anwendung den Zugriff auf ihr Konto bei einem anderen Dienst erlauben, ohne dieser Anwendung ihr Passwort zu verraten. Statt des Passworts erhält die Anwendung einen zeitlich begrenzten Zugriffsschlüssel, den sogenannten Access Token, der nur für die freigegebenen Bereiche gilt und sich jederzeit widerrufen lässt. Die aktuelle Fassung OAuth 2.0 ist seit Oktober 2012 als RFC 6749 der Internet-Standardisierungsorganisation IETF festgeschrieben.
Sie nutzen OAuth jedes Mal, wenn Sie auf einer Website „Mit Google anmelden“ oder „Mit Microsoft anmelden“ klicken, wenn ein Terminbuchungstool Ihren Kalender lesen darf oder wenn Sie Ihr Gmail-Postfach mit einem KI-Assistenten wie Claude oder ChatGPT verbinden. Das Passwort bleibt dabei immer beim Anbieter des Kontos, also bei Google, Microsoft oder Apple. OAuth regelt nur die Zugriffsrechte (Autorisierung), nicht die Frage, wer Sie sind (Authentifizierung). Diese zweite Aufgabe übernimmt die darauf aufbauende Erweiterung OpenID Connect.
Eine OAuth-Freigabe läuft in vier Schritten ab, an denen vier Parteien beteiligt sind. Der Kontoinhaber (Resource Owner) ist die Person, der die Daten gehören. Der Client ist die Anwendung, die Zugriff haben möchte, etwa ein Buchhaltungsprogramm oder ein KI-Assistent. Der Autorisierungsserver (Authorization Server) gehört zum Anbieter des Kontos und stellt die Zugriffsschlüssel aus. Ein Ressourcenserver (Resource Server) hält die eigentlichen Daten, etwa die E-Mails oder Kalendereinträge. Im ersten Schritt leitet die Anwendung den Nutzer zum Autorisierungsserver weiter. Dort meldet er sich wie gewohnt an. Im zweiten Schritt sieht er einen Zustimmungsbildschirm mit dem Namen der Anwendung und einer Liste der angeforderten Rechte. Stimmt er zu, schickt der Autorisierungsserver im dritten Schritt einen Einmal-Code an die Anwendung, die ihn im vierten Schritt gegen den Access Token eintauscht. Erst mit diesem Token darf die Anwendung beim Ressourcenserver Daten abrufen.
Der Zustimmungsbildschirm ist die wichtigste Stelle des gesamten Verfahrens, denn hier entscheidet der Nutzer, was die Anwendung darf. Google zeigt darin die angeforderten Berechtigungen sowie Name und Logo der Anwendung, wobei eigener Name und Logo laut Googles Hilfe zur App-Verifizierung erst nach einer Markenprüfung erscheinen. Bei ungeprüften Anwendungen, die sensible Daten anfordern, blendet Google laut seiner Verifizierungs-Hilfe für OAuth-Apps einen Warnhinweis ein, dass die App nicht überprüft wurde (im Original „Google hasn't verified this app“), und begrenzt sie auf 100 Nutzer. Microsoft kennzeichnet Herausgeber in seinem Dialog „Angeforderte Berechtigungen“ mit einem blauen Häkchen für verifizierte Anbieter oder mit dem Vermerk „Nicht verifiziert“. In der Dokumentation zum Zustimmungsdialog weist das Unternehmen darauf hin, dass der angezeigte App-Name vom Entwickler selbst stammt und nicht geprüft wird.
Die Rechte heißen im Standard Scopes. Ein Scope wie „Kalender lesen“ erlaubt genau das und nichts anderes, ein Scope „E-Mails senden“ dagegen deutlich mehr. Access Tokens sind meist nur kurz gültig, bei der Personalsoftware Personio zum Beispiel 24 Stunden. Damit der Nutzer nicht täglich neu zustimmen muss, gibt der Autorisierungsserver zusätzlich einen Refresh Token aus, mit dem die Anwendung im Hintergrund neue Access Tokens holt. Bei Microsoft taucht dieser Dauerzugriff im Zustimmungsdialog als eigene Berechtigung auf (technischer Name: offline_access). Entzieht der Nutzer einer Anwendung die Freigabe, werden ihre Tokens ungültig, das Passwort bleibt unverändert und alle anderen verbundenen Anwendungen laufen weiter.
Genau darin liegt der Unterschied zum Passwort-Weitergeben und zum API-Schlüssel. Wer einer Anwendung sein Passwort gibt, räumt ihr Vollzugriff ein und kann diesen nur durch eine Passwortänderung zurücknehmen, die dann alle anderen Anwendungen ebenfalls aussperrt. Der RFC 6749 nennt dieses Problem ausdrücklich als Grund für die Entwicklung des Standards. Ein API-Schlüssel ist eine lange Zeichenkette, die der Nutzer von Hand kopiert und in die fremde Anwendung einfügt. Er wirkt wie ein Generalschlüssel, hat je nach Anbieter kein oder ein sehr langes Ablaufdatum und verrät nicht, wofür er gerade benutzt wird. OAuth ersetzt das Kopieren durch ein Klick-Verfahren, bei dem der Nutzer den Schlüssel nie zu Gesicht bekommt und der Anbieter jede Freigabe einzeln protokolliert. Wie sich das in der Praxis auswirkt, zeigt der gehostete MCP-Server von ElevenLabs, der sich per OAuth in Claude einrichten lässt, während die frühere lokale Variante einen API-Schlüssel brauchte.
OAuth regelt nur Zugriffsrechte und trifft keine Aussage darüber, wer vor dem Bildschirm sitzt. Deshalb veröffentlichte die OpenID Foundation im Februar 2014 mit OpenID Connect (OIDC) eine Identitätsschicht, die auf OAuth 2.0 aufsetzt und zusätzlich einen ID Token mit der bestätigten Nutzerkennung liefert. Hinter jedem „Mit Google anmelden“-Knopf stecken beide Standards zusammen, Google beschreibt seine Anmeldung in der Entwicklerdoku zu Sign in with Google als „auf OAuth 2.0 basierend“ und führt sie in seiner Doku zu OpenID Connect als zertifizierte OpenID-Connect-Umsetzung. Der ältere Firmenstandard SAML 2.0 (Security Assertion Markup Language) aus dem Jahr 2005 löst die Einmalanmeldung im Unternehmensnetz mit XML-Dokumenten statt mit Tokens. Ein einheitliches Verfahren, bei dem sich Mitarbeiter einmal anmelden und danach alle Firmenanwendungen nutzen, nennt man Single Sign-on. Es lässt sich wahlweise mit SAML oder mit OpenID Connect umsetzen.
Die Geschichte des Standards begann im November 2006, als der Twitter-Entwickler Blaine Cook nach einem Weg suchte, Drittanbieter-Anwendungen ohne Passwort-Weitergabe an Twitter anzubinden. Im Dezember 2007 erschien OAuth Core 1.0, im April 2010 folgte die IETF-Fassung als RFC 5849. OAuth 2.0 von 2012 ist mit der Vorgängerversion nicht kompatibel und verzichtet auf kryptografische Signaturen zugunsten verschlüsselter HTTPS‑Verbindungen. Der bisherige Hauptautor Eran Hammer trat im Juli 2012 kurz vor der Fertigstellung zurück und ließ seinen Namen aus der Spezifikation streichen. In einem vom Fachmagazin The Register dokumentierten Blogbeitrag kritisierte er, der Standard sei so vage geraten, dass sich fast alles als „OAuth-2.0-konform“ bezeichnen lasse.
Seit Januar 2025 legt der RFC 9700 „Best Current Practice for OAuth 2.0 Security“ verbindlich fest, was sichere Umsetzungen einhalten müssen. Der sogenannte Password Grant, bei dem die Anwendung das Passwort doch wieder selbst entgegennimmt, darf nicht mehr verwendet werden. Auch vom Implicit Flow rät das Dokument ab. Öffentliche Clients wie Apps und Browser-Anwendungen müssen das Schutzverfahren PKCE (Proof Key for Code Exchange, RFC 7636 von 2015) einsetzen. Rücksprungadressen müssen zeichengenau mit der registrierten Adresse übereinstimmen. Parallel dazu entsteht OAuth 2.1, das diese Regeln und die wichtigsten Erweiterungen zu einer bereinigten Gesamtfassung zusammenführt. OAuth 2.1 liegt Stand August 2026 als IETF-Entwurf in der 15. Fassung vom März 2026 vor und ist noch kein offizieller RFC. Die Arbeitsgruppe will den Entwurf bis Dezember 2026 zur abschließenden Prüfung einreichen.
Weil OAuth den Zugriff so bequem macht, hat sich eine eigene Betrugsmasche entwickelt, das Consent Phishing. Der Angreifer registriert eine bösartige Anwendung mit harmlos klingendem Namen und schickt dem Opfer einen echten OAuth-Link. Das Opfer meldet sich beim echten Google oder Microsoft an, sieht einen echten Zustimmungsbildschirm und klickt auf „Zulassen“. Ein Passwort wird nie abgefragt, eine Zwei-Faktor-Abfrage läuft regulär durch, und trotzdem hat der Angreifer danach Zugriff auf das Postfach. Microsoft beschreibt das Muster in seinem Sicherheitsblog vom Juli 2021 unter dem Namen „illicit consent grant“. Das bekannteste Beispiel war ein Wurm im Mai 2017, der sich als Google-Docs-Freigabe tarnte, nach der Zustimmung die Kontaktliste auslas und sich selbst weiterverschickte. Google sprach in seiner Stellungnahme von weniger als 0,1 Prozent betroffener Nutzer und verschärfte danach die Prüfung von Drittanbieter-Apps. Der Sicherheitsanbieter Proofpoint zählte in seiner Auswertung für das Jahr 2020 über 180 bösartige OAuth-Anwendungen, und in 10 Prozent der untersuchten Unternehmen hatte mindestens eine solche App eine Freigabe erhalten.
Im Januar 2024 meldete Microsoft einen Angriff der russischen Gruppe Midnight Blizzard. Die Angreifer kamen über ein altes Testkonto an eine vergessene Test-OAuth-Anwendung mit erhöhten Rechten. Darüber legten sie laut Microsofts Analyse für Sicherheitsteams weitere bösartige OAuth-Apps mit Postfachzugriff an. Betroffen waren laut der Erstmeldung von Microsoft unter anderem die Postfächer der Unternehmensführung. Zwischen dem 8. und 18. August 2025 nutzte eine Gruppe gestohlene OAuth-Tokens der Chat-Software Drift, um nach Angaben von Googles Threat-Intelligence-Team Daten aus den Salesforce-Systemen zahlreicher Drift-Kunden abzuziehen. Salesforce und der Drift-Eigentümer Salesloft widerriefen daraufhin sämtliche Tokens der Anwendung. In beiden Fällen funktionierten die gestohlenen Tokens so lange, bis jemand sie widerrief, und in beiden Fällen lief der Zugriff über eine Anwendung, die im Unternehmen niemand mehr im Blick hatte.
Das Model Context Protocol (MCP) ist der offene Standard für die Anbindung von Diensten an KI‑Assistenten. Seine Autorisierungs-Spezifikation legt seit der Fassung vom März 2025 fest, dass MCP-Server mit Zugriffsschutz diesen nach OAuth 2.1 umsetzen müssen, inklusive PKCE-Pflicht für die Clients. Seit der Fassung vom Juni 2025 tritt der MCP-Server dabei als Ressourcenserver auf. Die aktuelle Fassung vom Juli 2026 stellt die automatische Registrierung von KI-Clients bei fremden Diensten auf ein neues Verfahren um (Client ID Metadata Documents). OpenAI verlangt für angebundene MCP-Server mit Anmeldung in ChatGPT laut seiner Entwicklerdoku zur MCP-Autorisierung einen OAuth-2.1-Ablauf nach dieser MCP‑Vorgabe. Anthropic formuliert es in der Hilfe zu Custom Connectors so, dass Claude im Namen des Nutzers handelt, „ohne jemals das eigentliche Passwort zu sehen“. Der Scope bestimmt dabei, was ein KI-Agent überhaupt tun kann. Eine Freigabe „Kalender lesen“ reicht, damit die KI freie Termine findet. Erst eine Freigabe zum Senden erlaubt ihr, eine E-Mail zu verschicken.
Die meisten Betriebe haben OAuth längst im Einsatz, ohne es zu wissen, und das erste Mal bemerkt haben es viele beim E-Mail-Postfach. Microsoft hat die Anmeldung mit Benutzername und Passwort (Basic Authentication) für Exchange Online laut seiner Abschaltungs-Dokumentation seit Anfang 2023 in allen Firmenkonten endgültig deaktiviert. Mailprogramme wie Thunderbird melden sich seitdem per OAuth an, alte Outlook-Versionen ohne diese Funktion bleiben ausgesperrt. Google folgte am 14. März 2025 und schaltete den Zugriff für „weniger sichere Apps“ für alle Konten ab, wie die Workspace-Hilfe zur Umstellung auf OAuth beschreibt. Wer seitdem in einem alten Mailprogramm die Meldung sieht, Benutzername oder Passwort seien falsch, obwohl beides stimmt, muss das Konto entfernen und mit „Mit Google anmelden“ neu einrichten. Der nächste Stichtag betrifft Drucker und Scanner mit Scan-to-Mail-Funktion sowie ältere Rechnungsprogramme, die über SMTP versenden. Microsoft schaltet laut Ankündigung vom Januar 2026 die Passwort-Anmeldung für den SMTP-Versand Ende Dezember 2026 standardmäßig ab. Administratoren können sie danach vorerst wieder einschalten, neue Konten bekommen sie gar nicht mehr.
Wer Abläufe mit Make oder Zapier automatisiert, richtet jede Verbindung zu Gmail, Outlook, Google Sheets oder dem Online-Kalender per OAuth ein. Zapier nennt OAuth in seiner Plattform-Dokumentation das bevorzugte Verfahren, weil Nutzer sich im Anmeldefenster des jeweiligen Anbieters anmelden, statt Zugangsdaten in Zapier einzutragen. Läuft eine Verbindung ab oder entzieht ein Mitarbeiter die Freigabe, markiert Zapier sie als abgelaufen, und die Automatisierung bleibt stehen, bis jemand sie neu verbindet. Das Terminbuchungstool Calendly schreibt in seinen Sicherheitshinweisen, es vermeide das Einsammeln fremder Passwörter und verbinde Google- und Microsoft-365-Kalender deshalb per OAuth. Nur für iCloud-Kalender benötigt das Tool weiterhin ein Passwort, das es verschlüsselt speichert. Drittanbieter-Tools, die Bewertungen oder Beiträge im Google Unternehmensprofil verwalten, benötigen ebenfalls eine einmalige OAuth-Zustimmung des Profilinhabers.
DATEV wickelt die Anbindung von Fremdsoftware an seine Datenservices laut seiner Erklärseite zu OpenID Connect über OAuth 2.0 und OpenID Connect ab. Ein Betrieb meldet sich in seinem Rechnungsprogramm mit dem DATEV-Login an, und die Software erhält einen Token für genau die freigegebenen Dienste, etwa die Belegübergabe an den Steuerberater. Lexware Office bietet Softwareherstellern eine Partner-Schnittstelle mit OAuth 2.0 und PKCE, Endkunden erzeugen für eigene Anbindungen dagegen weiterhin einen klassischen API-Schlüssel mit maximal 24 Monaten Laufzeit. Bei sevDesk läuft der Zugriff ausschließlich über einen festen API-Schlüssel aus den Einstellungen, und die Schnittstelle des Shopsystems WooCommerce arbeitet mit einem Schlüsselpaar aus Consumer Key und Consumer Secret. Wer Angebote für Branchensoftware vergleicht, sollte deshalb nicht nur fragen, ob eine Schnittstelle existiert, sondern auch, wie die Freigabe dafür abläuft.
Verbindet ein Handwerksbetrieb Gmail und Google Kalender mit Claude, um sich morgens die Kundenanfragen zusammenfassen und Antworten entwerfen zu lassen, läuft die Einrichtung über den Google-Zustimmungsbildschirm. Dasselbe gilt für die Anbindung von Diensten an ChatGPT, an Microsoft Copilot oder an Gemini. Ein Betrieb, der einen Voice-Agenten bei ElevenLabs betreibt, etwa als KI-Telefonassistenten, verwaltet ihn seit 2026 per OAuth-Freigabe direkt im Claude-Chat, statt einen API-Schlüssel in eine Konfigurationsdatei zu kopieren.
Die Freigaben lassen sich jederzeit prüfen und entziehen, und diese Kontrolle gehört in jeden Betrieb auf die Liste der regelmäßigen Aufgaben. Für Google-Konten liegt die Übersicht auf der Seite „Drittanbieterverbindungen“ im Google-Konto, dort steht bei jeder App, welche Daten sie lesen darf, und die Klickfolge „Details ansehen“, „Zugriff entfernen“, „Bestätigen“ beendet die Verbindung. Bei Microsoft-365-Firmenkonten führt der Weg über das Portal myapplications.microsoft.com und den Punkt „Berechtigungen widerrufen“. Private Microsoft-Konten verwalten ihre Apps unter microsoft.com/consent. Apple-Nutzer finden die Liste auf dem iPhone unter „Einstellungen“, „eigener Name“, „Mit Apple anmelden“, wie Apple in seiner Support-Anleitung beschreibt. Ein sinnvoller Rhythmus ist ein Durchgang pro Quartal sowie jedes Mal, wenn ein Mitarbeiter den Betrieb verlässt, denn dessen persönliche Freigaben an Tools und Automatisierungen erlöschen nicht von selbst.
Beim Zustimmungsbildschirm selbst gibt es drei Alarmzeichen. Erstens der Vermerk „Nicht verifiziert“ bei Microsoft oder der Hinweis auf eine nicht überprüfte App bei Google, wenn es sich nicht um ein eigenes Testprojekt handelt. Zweitens Berechtigungen, die zum Zweck nicht passen, etwa wenn ein Tool zum Terminabgleich das Recht „E-Mails senden“ oder Vollzugriff auf alle Postfächer anfordert. Drittens bei Microsoft-Firmenkonten das Kästchen „Zustimmung im Namen Ihrer Organisation“, das ein Administrator nur dann setzen sollte, wenn die Anwendung wirklich für alle Mitarbeiter freigegeben werden soll. Wer unsicher ist, klickt auf „Abbrechen“, denn ein Abbruch kostet nichts und die Freigabe lässt sich jederzeit nachholen.
