OAuth 2.0.
OAuth 2.0 ist ein offener Standard, mit dem eine Anwendung im Namen einer Person auf deren Daten bei einem anderen Dienst zugreifen darf, ohne das Passwort zu kennen. Die Person bestätigt beim Dienst selbst, welche Rechte sie freigibt, und die Anwendung erhält dafür ein zeitlich begrenztes Zugriffstoken.
OAuth 2.0 — ausführlich erklärt
Vor OAuth war die Verbindung zweier Dienste oft unsicher: Wer seine Kontakte aus einem Mailkonto in eine andere App übernehmen wollte, gab dieser App sein Mailpasswort. Die App hatte damit vollen Zugriff, für immer, und das Passwort lag in einem fremden System. OAuth 2.0, als RFC 6749 im Jahr 2012 standardisiert, löst dieses Problem mit einem Umweg: Die Person meldet sich beim eigentlichen Dienst an, sieht dort, welche Rechte die App verlangt, und bestätigt. Die App erhält nicht das Passwort, sondern ein Token mit genau diesen Rechten.
Im Standard gibt es vier Rollen. Der Resource Owner ist die Person, der die Daten gehören. Der Client ist die Anwendung, die zugreifen will. Der Authorization Server prüft die Identität und stellt Tokens aus. Der Resource Server hält die Daten und akzeptiert gültige Tokens. Die freigegebenen Rechte heissen Scopes, etwa «Kalender lesen» oder «Rechnungen erstellen». Das Access Token ist kurzlebig; ein Refresh Token erlaubt, neue Access Tokens zu holen, ohne die Person erneut zu fragen. Für Web- und Mobile-Apps gilt heute der Authorization Code Flow mit PKCE als empfohlener Ablauf.
Wichtig ist eine Abgrenzung: OAuth 2.0 regelt die Autorisierung, also «was darf diese App», nicht die Authentifizierung, also «wer ist diese Person». Für das Anmelden mit einem bestehenden Konto, etwa «Mit Google anmelden» oder «Mit Microsoft anmelden», wird darauf eine eigene Schicht gesetzt: OpenID Connect. Sie liefert zusätzlich ein ID Token mit Angaben zur Identität. Dieses Paar aus OAuth 2.0 und OpenID Connect ist auch die häufigste technische Grundlage für Single Sign-on in Unternehmen.
Für KMU ist OAuth vor allem in zwei Situationen relevant. Erstens, wenn eine eigene Anwendung Daten aus Google Workspace, Microsoft 365, einer Buchhaltungssoftware oder einem Werbekonto lesen soll: Dann wird die Verbindung über OAuth hergestellt, und die Freigabe lässt sich jederzeit im jeweiligen Konto widerrufen. Zweitens, wenn eine eigene Plattform, etwa ein Kundenportal, anderen Systemen kontrollierten Zugriff über eine API geben soll. Dann wird die eigene Anwendung selbst zum Authorization Server oder nutzt einen bestehenden Identitätsdienst.
Typische Fehler bei OAuth-Integrationen
Der häufigste Fehler sind zu breite Scopes: Eine App, die nur Termine lesen muss, verlangt vollen Schreibzugriff auf das Postfach, weil es bequemer ist. Das widerspricht dem Prinzip der minimalen Rechte und schreckt Nutzer bei der Freigabe zu Recht ab. Der zweite Fehler ist die unsichere Aufbewahrung von Refresh Tokens: Sie sind langlebig und gehören verschlüsselt in die Datenbank, nie in den Browser-Speicher oder in Protokolldateien.
Drittens werden Weiterleitungsadressen zu offen konfiguriert, was Angreifern erlaubt, Autorisierungscodes abzufangen. Viertens fehlt eine saubere Behandlung des Widerrufs: Entzieht jemand die Freigabe, muss die Anwendung das erkennen und verständlich reagieren, statt mit kryptischen Fehlern abzubrechen.
Beispiel: Terminbuchung mit dem Kalender der Praxis
Ein Beispiel: Eine Physiotherapiepraxis mit vier Therapeutinnen will, dass ihre Online-Buchung freie Zeiten direkt aus den bestehenden Microsoft-365-Kalendern liest und neue Termine dort einträgt. Statt die Passwörter der Therapeutinnen im Buchungssystem zu speichern, verbindet jede ihren Kalender einmal per OAuth. Sie sieht dabei bei Microsoft, dass die Buchung nur Kalender lesen und Termine eintragen darf, nicht aber E-Mails lesen.
Verlässt eine Therapeutin die Praxis, wird ihr Konto deaktiviert, und die Verbindung endet automatisch. Ändert sie ihr Passwort, bleibt die Buchung trotzdem verbunden, weil sie das Passwort nie kannte. Solche Integrationen gehören zum Alltag, wenn wir eine Web-App entwickeln oder Individualsoftware mit bestehenden Werkzeugen verbinden.
Weiterführende Seite
Single Sign-on (SSO)Häufige Fragen zu OAuth 2.0
Nicht im engeren Sinn. OAuth 2.0 regelt, welche Rechte eine Anwendung erhält. Für das Anmelden mit einem bestehenden Konto wird OpenID Connect verwendet, das auf OAuth 2.0 aufbaut und zusätzlich bestätigt, wer die Person ist. Im Alltag werden beide oft zusammen als «OAuth-Login» bezeichnet.
Ein Scope beschreibt ein bestimmtes Recht, das eine Anwendung anfordert, zum Beispiel «Kalender lesen» oder «Kontakte bearbeiten». Die Person sieht diese Liste bei der Freigabe. Gute Anwendungen verlangen nur die Scopes, die sie wirklich brauchen.
In den Kontoeinstellungen des jeweiligen Dienstes, etwa bei Google unter «Drittanbieter-Apps mit Kontozugriff» oder bei Microsoft unter den App-Berechtigungen. Nach dem Widerruf werden die Tokens ungültig und die Anwendung kann nicht mehr zugreifen.
Weitere Begriffe mit „O“
Organic Traffic
Organic Traffic beschreibt Besucher, die über unbezahlte Suchergebnisse auf Ihre Website kommen — al...
Open Graph (og:-Tags)
Open Graph ist ein Meta-Tag-Protokoll, das steuert, wie eine Webseite beim Teilen in sozialen Netzwe...
OpenAI Ads Manager
Der OpenAI Ads Manager ist die Oberfläche, in der Anzeigen für ChatGPT angelegt, gesteuert und ausge...
Bereit für Ihr Projekt?
Wenden Sie dieses Wissen auf Ihre Website an — DLM Digital hilft Ihnen dabei.
OAuth 2.0 in der Praxis
Wie der Begriff im Alltag von Schweizer KMU auftaucht — vertieft in Artikeln aus dem DLM Magazin.