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.