Was ist OAuth?
OAuth (Open Authorization) ist ein offener Standard für die Autorisierung von Anwendungen auf Basis der bestehenden Anmeldung in einem anderen Dienst. In Verbindung mit OpenID wird OAuth häufig für das Einloggen auf Websites verwendet, ohne dafür ein neues Benutzerkonto anlegen zu müssen. OAuth ermöglicht die sichere Authentifizierung von Drittdiensten, ohne dabei die Zugangsdaten des Benutzers weiterzugeben.
OAuth einfach erklärt
Wer im Internet schon einmal die Funktion “Mit Google anmelden” oder “Mit Facebook anmelden” verwendet hat, um sich auf einer Website zu registrieren ohne dafür ein eigenes Konto zu erstellen, der hatte bereits mit OAuth zu tun. Das Open Authentication Protokoll erlaubt es Endbenutzern, Drittanwendungen Zugriff auf Daten und Funktionen innerhalb eines anderen Dienstes zu gewähren, um z.B. die eigene Identität zu bestätigen oder Services miteinander zu verknüpfen (Beispiel: Social Media Plugins).
Für Endanwender ermöglicht OAuth somit eine Art von Single Sign-On (SSO) im Internet, indem sich User über ein Konto auf vielen verschiedenen Websites anmelden können. Entscheidend ist dabei, dass Webseiten über OAuth zwar Zugang zu bestimmten Informationen und Funktionen innerhalb eines Dienstes erhalten, für diese Autorisierung aber das Passwort des Benutzers nicht geteilt wird. Die Freigabe erfolgt stattdessen über ein Zugriffstoken, welches auf Anfrage erstellt und von einem Autorisierungsserver überprüft wird.
OAuth selbst ist zwar nicht für die Authentifizierung von Benutzern gedacht, wird jedoch in Verbindung mit OpenID Connect von zahlreichen Websites dafür verwendet.
Wie genau funktioniert OAuth?
Im OAuth-Framework existieren vier Rollen:
Resource Owner: Der Account-Eigentümer, der einem Drittdienst Zugriff gewährt.
Resource Server: Der Dienst, dessen Konto der User für die Freigabe verwendet (z.B. Facebook-Konto)
Client: Die Anwendung, die mit Zustimmung des Benutzers Zugriff erhält (z.B. Doodle-Abstimmung)
Authorization Server: Der Server, der den Account-Eigentümer authentifiziert und das Access Token an den Client ausstellt. Da größere Dienste meist eigene Autorisierungsserver betreiben, sind Resource Server und Authorization Server oft ident.
Die Verwendung von OAuth lässt sich am besten mit einem Beispiel erklären: Ein Benutzer (Resource Owner) möchte sein Google-Konto in einem Webshop (Client) verwenden und klickt auf den entsprechenden Button. Der Client schickt eine Anfrage an Google (Authorization Server) und öffnet ein eigenes Fenster, in dem der User sich anmeldet. Nach der Bestätigung durch den Benutzer schickt der Autorisierungserver ein Access Token an den Client. Mit diesem Access Token erhält der Webshop Zugriff auf den Ressourcenserver und kann den Besucher seinem Google-Konto zuordnen.
Das Access Token ermöglicht den Zugriff auf bestimmte Funktionen innerhalb des zuvor festgelegten Rahmens (Scope), z.B. Zugang zu grundlegenden Informationen über einen Benutzer oder der Schnittstelle (API) eines Dienstes. Dadurch können Drittanwendungen z.B. Kontakte aus sozialen Netzwerken importieren, in unserem Auftrag Beiträge oder Bilder posten, Fotos in Cloud-Speicher hochladen oder Termine in unserem Kalender anlegen.
Die meisten von uns kennen OAuth aus dem Web, das Protokoll wird aber auch von Cloud-Anwendungen wie Azure AD verwendet.
Unterschied OAuth vs. OAuth 2.0
Bei OAuth 2.0 handelt es sich um eine komplette Überarbeitung des ursprünglichen OAuth-Protokolls, die 2012 fertiggestellt wurde und OAuth 1.0 weitgehend abgelöst hat. Aufgrund technischer Unterschiede wie der Trennung von Resource Server und Authorization Server sind die beiden Standards nicht miteinander kompatibel. OAuth 2.0 bietet eine bessere Unterstützung von mobilen und Desktop-Anwendungen sowie eine zeitliche Limitierung von Access Tokens, die über Refresh Tokens erneuert werden müssen.
Allerdings gibt es auch Kritik an OAuth 2.0: Eran Hammer-Lahav, über lange Zeit der leitende Entwickler des Standards, verlässt die Arbeitsgruppe 2012 aufgrund großer Differenzen, die er in einem Blogpost zusammenfasst. Seine Einwände gegen OAuth 2.0: Die Komplexität des Standards werde in der Praxis zur unsicheren Implementierung in vielen Anwendungsfällen führen, zumal das neue Protokoll keine verpflichtende Verschlüsselung mehr enthält, sondern sich gänzlich auf die Übermittlung per TLS verlässt.
Best Practices im Access Management in Microsoft Umgebungen
Dieses Whitepaper enthält eine detaillierte Anleitung zur korrekten Einstellung von Berechtigungsstrukturen mit technischen Detailinformationen.