Das Problem, das OAuth löst
Früher war es üblich, einem Programm einfach das eigene Passwort zu geben, damit es zum Beispiel auf das Postfach zugreifen konnte. Das Programm hatte dann vollen Zugriff, konnte alles lesen und ändern, und wer den Zugriff entziehen wollte, musste das Passwort ändern – für alle Anwendungen gleichzeitig.
OAuth trennt das sauber. Du meldest dich beim eigentlichen Dienst selbst an, siehst, welche Rechte die Anwendung haben möchte, und stimmst zu oder nicht. Die Anwendung bekommt danach ein Token, das nur für diese Rechte gilt, ablaufen kann und sich einzeln widerrufen lässt. Dein Passwort sieht sie nie.
Die vier Rollen
Der Standard OAuth 2.0, 2012 als RFC 6749 veröffentlicht, beschreibt vier Beteiligte:
- Ressourcenbesitzer: du – die Person, der die Daten gehören und die den Zugriff erlaubt
- Client: die Anwendung, die Zugriff haben möchte, etwa ein Planungs-Tool, das deinen Kalender lesen soll
- Autorisierungsserver: der Teil des Dienstes, bei dem du dich anmeldest und zustimmst und der die Tokens ausstellt
- Ressourcenserver: der Teil des Dienstes, der die Daten hält und bei jeder Anfrage das Token prüft
Bei großen Anbietern sind Autorisierungs- und Ressourcenserver meist dieselbe Firma, aber technisch getrennt.
Tokens und Berechtigungen
Das Zugangstoken (Access Token) ist der Ausweis, den die Anwendung bei jeder Anfrage vorzeigt. Es ist meist nur kurz gültig. Damit du nicht ständig neu zustimmen musst, gibt es oft zusätzlich ein Aktualisierungstoken (Refresh Token), mit dem die Anwendung sich im Hintergrund ein neues Zugangstoken holt.
Welche Rechte ein Token gewährt, bestimmen die Scopes – etwa „Kalender lesen“, aber nicht „Kalender ändern“ oder „E-Mails senden“. Im Zustimmungsfenster stehen genau diese Scopes. Es lohnt sich, sie zu lesen: Will ein einfaches Notiz-Tool Zugriff auf dein gesamtes Postfach, ist Vorsicht angebracht.
Ein gültiges Token funktioniert wie ein Schlüssel: Wer es hat, kann es benutzen. Deshalb werden Tokens nur über HTTPS übertragen, geschützt gespeichert und laufen nach kurzer Zeit ab. Für Apps und Webanwendungen ist heute der sogenannte Authorization-Code-Ablauf mit PKCE üblich – eine Ergänzung, die verhindert, dass ein abgefangener Zwischencode von Fremden eingelöst werden kann.
OAuth, Login und Single Sign-on
Streng genommen regelt OAuth nur, was eine Anwendung darf (Autorisierung), nicht wer du bist (Authentifizierung). Für das Anmelden mit einem bestehenden Konto – die bekannten Knöpfe „Mit Google anmelden“ oder „Mit Microsoft anmelden“ – baut der Standard OpenID Connect auf OAuth auf und ergänzt die Information über die Identität.
Damit ist OAuth auch eine Grundlage für Single Sign-on in vielen Cloud-Diensten. Und wenn KI-Assistenten über einen Connector auf Mail, Kalender oder Dateien zugreifen, läuft die Freigabe häufig ebenfalls über OAuth.
Sabine Berger möchte, dass ein Terminbuchungs-Tool ihre freien Zeiten kennt. Sie klickt auf „Kalender verbinden“ und landet auf der Anmeldeseite ihres Kalenderanbieters – nicht beim Tool.
Dort steht: „Das Tool möchte: Ihre Kalender anzeigen; Termine erstellen.“ Sie stimmt zu, das Tool erhält ein Token. Ein halbes Jahr später wechselt sie das Werkzeug und entzieht den Zugriff in den Kontoeinstellungen des Kalenderanbieters mit einem Klick – ihr Passwort muss sie dafür nicht ändern.
Dieser Eintrag dient der allgemeinen Information und ersetzt keine individuelle Beratung.