OAuth
OAuth?
OAuth steht für Open Authorization und ist ein Standardprotokoll, mit dem Sie einer Anwendung Zugriff auf Daten oder Funktionen innerhalb einer anderen Anwendung gewähren können. OAuth verwendet dafür digitale Tokens, sodass Benutzernamen und Passwörter nicht zwischen diesen Anwendungen geteilt werden müssen. Dies macht die Zusammenarbeit einfacher und sicherer.
Was ist OAuth?
Mit OAuth können Sie Autorisierungseinstellungen auf standardisierte Weise von einer Anwendung oder einem Dienst an einen anderen übertragen. Das klingt zunächst abstrakt, lässt sich jedoch mit der Schlüsselkarte vergleichen, die Sie beim Check-in in einem Hotel erhalten. Der Rezeptionist gibt Ihnen als Gast natürlich nicht den Generalschlüssel des Hotels. Stattdessen erhalten Sie eine Schlüsselkarte mit genau Ihren Berechtigungen. Wie jeder Gast können Sie die Eingangstür öffnen, haben Zugang zu Ihrem eigenen Zimmer und, abhängig von Ihrer Buchung, beispielsweise auch zum Fitnessbereich und zur Tiefgarage.
OAuth funktioniert in digitalen Umgebungen ähnlich. Ein „Authorization Server“ erteilt einer Zielanwendung Berechtigungen mithilfe eines Access Tokens. Die Anwendung, für die das Token bestimmt ist, erhält dadurch Berechtigungen für bestimmte Daten und Funktionen, die über APIs erreichbar sind.
Wie funktioniert OAuth?
Dies lässt sich am besten anhand der Art von Anwendung veranschaulichen, für die OAuth ursprünglich entwickelt wurde. Im Cloud-Zeitalter benötigen Anwendungen häufig Daten, die an anderer Stelle in der Cloud gespeichert sind. Oder sie nutzen Funktionen in anderen Systemen. Wie lassen sich diese Daten und Funktionen für andere Anwendungen zugänglich machen? Dafür gibt es zwei Ansätze: die herkömmliche Lösung vor der Entwicklung von OAuth und die Lösung mit OAuth.
Herkömmlicher Zugriff auf Online-Ressourcen ohne OAuth
Nehmen wir das Beispiel eines intelligenten Online-Tools zur Fotobearbeitung. Sie möchten es verwenden, um die Fotos zu bearbeiten, die Sie in Ihrem Google Drive speichern. Dafür muss die Anwendung Zugriff auf Ihr Google Drive erhalten. In der Zeit vor OAuth geschah dies, indem Sie sich über eine API direkt aus der Anwendung bei Ihrem Google-Konto anmeldeten. Dafür mussten Ihr Benutzername und Passwort verwendet werden. Das Ergebnis war, dass die Anwendung Zugriff auf Ihre Fotos, aber auch auf alle anderen Funktionen und Daten in Ihrem Google-Konto erhielt. Genau das ist nicht wünschenswert, weshalb OAuth entwickelt wurde.
Zugriff auf Online-Ressourcen mit OAuth
Mit OAuth ist es nicht mehr erforderlich, sich innerhalb dieser Anwendung bei Ihrem Google-Konto anzumelden. Stattdessen erhalten Sie eine Meldung, dass die Anwendung Zugriff auf Ihre Google-Drive-Fotos erhalten möchte und Sie sich bei Ihrem Google-Konto anmelden müssen, um dafür Ihre Zustimmung zu erteilen.
Wenn Sie sich dann bei Ihrem Konto anmelden, werden Sie automatisch gefragt, ob Sie der Anwendung erlauben möchten, Fotos in Ihrem Drive zu bearbeiten. Bestätigen Sie diese Anfrage, sendet Google, das hier als Authorization Server fungiert, ein Access Token an die betreffende Anwendung. Dadurch erhält sie Zugriff auf Ihr Google-Konto, jedoch ausschließlich zum Anzeigen und Bearbeiten der Fotos. Weitergehender Zugriff bleibt blockiert.
Für Benutzer wirken die Szenarien ähnlich, denn in beiden Fällen melden Sie sich mit Ihren Google-Zugangsdaten an. Ohne OAuth geschieht dies jedoch „innerhalb“ der Anwendung und Sie öffnen damit automatisch die Tür zu all Ihren Daten. Mit OAuth melden Sie sich auf reguläre Weise bei Ihrem Google-Konto an und erteilen der Anwendung nur eine spezifische Berechtigung: Fotos anzeigen und bearbeiten.
Vorteile von OAuth?
Dadurch bietet OAuth mehrere Vorteile:
Wir können Systemen Autorisierungen erteilen, ohne das Passwort einer Person teilen zu müssen. Dadurch besteht eine klare Trennung zwischen der Authentifizierung eines Benutzers und den erteilten Autorisierungen.
Wir verfügen über einen Mechanismus für granulare Autorisierungen. Bei der Verwendung persönlicher Anmeldedaten erhält eine Anwendung automatisch auch den vollständigen Berechtigungssatz einer Person. Mit OAuth können Sie deutlich spezifischere Autorisierungen konfigurieren. Berechtigungen lassen sich zudem einfach widerrufen, ohne das Passwort ändern zu müssen.
Es gibt nun ein Standardprotokoll, das zwischen verschiedenen Arten von Systemen und Anwendungen unterschiedlicher Anbieter und Dienstleister eingesetzt werden kann.
Wir vereinfachen die Verwaltung von Zugriffsrechten, da wir detaillierte Zugriffsrechte für mehrere Systeme zentral konfigurieren können.
Beispiele für OAuth in der Praxis
Es gibt zahlreiche Beispiele für den Einsatz von OAuth. Besonders hilfreich ist jedoch die Unterscheidung zwischen zwei Arten von Szenarien. Für beide geben wir ein Beispiel.
Anwendungstyp 1: Delegierte Autorisierungen
Das zuvor genannte Szenario mit der Fotobearbeitungsanwendung ist ein Beispiel, bei dem OAuth ausschließlich verwendet wird, um spezifische Berechtigungen an andere Anwendungen zu delegieren. Bei der Fotobearbeitungsanwendung wird Ihnen als Benutzer beispielsweise folgende Aufforderung angezeigt:
„Diese App möchte auf Fotos in Ihrem Google Drive zugreifen. Melden Sie sich bei Google an und erteilen Sie die Berechtigung, Ihre Fotos zu verwenden.“
Indem Sie sich anschließend bei Ihrem Google-Konto anmelden und die Anfrage bestätigen, erteilen Sie diese Zustimmung. Die Anwendung erhält dann ein Access Token mit den exakten Berechtigungen, erfährt jedoch darüber hinaus nichts über den Benutzer. Es werden keine Identitätsdaten geteilt, es handelt sich ausschließlich um einen technischen Zugriff auf Online-Ressourcen.
Anwendungstyp 2: Delegierte Authentifizierung, beispielsweise Single Sign-On
OAuth wird heute jedoch auch eingesetzt, um beispielsweise Single-Sign-On-Szenarien, SSO, zu unterstützen. Angenommen, Sie möchten die Fotobearbeitungsanwendung nicht nur spontan verwenden, sondern ein Konto anlegen, um mehr Funktionen zu nutzen. Der traditionelle Ansatz besteht darin, dass Sie dafür ein Konto erstellen, Ihre personenbezogenen Daten eingeben und ein Passwort festlegen müssen. Glücklicherweise gibt es heute einfachere Lösungen, beispielsweise die Anmeldung über Google oder ein anderes Social-Media-Konto. In diesem Fall zeigt die Anwendung eine Meldung mit folgendem Inhalt an:
„Diese App möchte Ihre Identität verwenden, um Sie anzumelden. Melden Sie sich bei Google an und erteilen Sie die Berechtigung, Ihren Namen, Ihre E-Mail-Adresse und Ihre Profilinformationen zu teilen.“
Das ist praktisch, da Sie für dieses Konto keinen separaten Benutzernamen und kein separates Passwort verwenden müssen. Sobald Sie bei Google angemeldet sind, haben Sie auch als registrierter Benutzer Zugriff auf die Anwendung. Dieser Mechanismus steht mit verschiedenen privaten Konten zur Verfügung, darunter Google, Microsoft und Facebook.
Auch innerhalb von Organisationen wird solche SSO-Funktionalität intensiv genutzt. Dabei kommt ein sogenannter Identity Provider wie Google Workspace, Microsoft Active Directory oder Entra ID zum Einsatz. Auch IAM-Anbieter wie HelloID verfügen über einen integrierten Identity Provider.
Unterschied zwischen delegierter Autorisierung und Authentifizierung
Bei der ersten Anwendung nutzen Sie OAuth also auf die ursprüngliche Weise. Mithilfe eines Tokens gewähren Sie Zugriff auf spezifische technische Ressourcen. Die Identität des Benutzers spielt dabei keine Rolle.
Im zweiten Szenario verwenden Sie OAuth, um auch Identitätsdaten zu teilen. Dafür wurde als Ergänzung zu OAuth eine zusätzliche Authentifizierungsschicht entwickelt. Diese Authentifizierungsschicht ist OpenID Connect, OIDC.
OAuth 2.0
Bei den vorangegangenen Beispielen geht es übrigens um OAuth 2.0. Die erste Version von OAuth wurde 2007 entwickelt. Sie unterstützte nur Websites und basierte noch weitgehend auf proprietären Protokollen, unter anderem von Google. Im Jahr 2012 wurde OAuth 2.0 eingeführt, das deutlich leistungsfähiger ist und auch Anwendungen sowie mobile Apps unterstützt. Für diese Version lieferten wesentlich mehr große Technologieunternehmen Input, was zu einer vollständigen Neugestaltung führte. Kurz nach der Veröffentlichung von OAuth 2.0 wurde zudem die OpenID-Connect-Schicht für die Authentifizierung ergänzt.
OAuth versus OIDC
OpenID Connect, OIDC, ist zusätzliche Funktionalität, die OAuth ergänzt, um auch Identitätsdaten zu teilen. Die grundlegenden Abläufe für Autorisierung und Authentifizierung sind vergleichbar, die übertragenen Informationen unterscheiden sich jedoch. Statt eines Access Tokens mit Autorisierungen wird für Identitätsdaten ein ID Token übermittelt. Während Access Tokens im Authorization Server erstellt werden, wird das ID Token in einem OIDC-Provider generiert.
Dies sind die funktionalen Begriffe. Wie die Funktionalität in der Praxis implementiert wird, unterscheidet sich je nach Anbieter. Wesentlich ist, dass Sie mit OAuth Autorisierungen zentral erteilen und mit OIDC die Identität einer Person zentral bestätigen können. In einem SSO-Szenario muss sich eine Person zu Beginn einer Sitzung einmalig beispielsweise mit einem Passwort und Multi-Faktor-Authentifizierung anmelden. Nutzt der Benutzer während der Sitzung eine oder mehrere Anwendungen, wird die Identität jeweils unmittelbar bestätigt, ohne dass eine separate Anmeldung erforderlich ist. „Unter der Haube“ geschieht dies mithilfe des ID Tokens.
OAuth versus SAML
OAuth wird häufig mit SAML, Security Assertion Markup Language, verglichen. Während OAuth primär für Cloud-Anwendungen und mobile Anwendungen entwickelt wurde, richtete sich SAML ursprünglich auf geschäftliche Anwendungen. Zudem ist SAML weniger für die Erteilung von Autorisierungen wie OAuth vorgesehen. Mit SAML können Sie zwar grundlegende Berechtigungen konfigurieren, die wichtigste Funktion von SAML liegt jedoch in der Authentifizierung und im SSO.
Funktional ist SAML daher vor allem mit OIDC vergleichbar. Beide SSO-Lösungen werden in der Praxis in professionellen IAM-Umgebungen eingesetzt. Die HelloID Access Management Module unterstützt beide Technologien.