OAuth

Was ist OAuth?

OAuth (Open Authorization) ist ein offener Standard für die Token-basierte Autorisierung im Internet. OAuth ermöglicht die Nutzung der Kontoinformationen eines Endnutzers durch Drittanbieterdienste wie Facebook und Google, ohne dass die Anmeldedaten des Nutzers an den Drittanbieter weitergegeben werden. Es fungiert als Vermittler im Namen des Endnutzers und stellt dem Drittanbieterdienst ein Zugriffs-Token zur Verfügung, das die Freigabe bestimmter Kontoinformationen erlaubt. Der Prozess zur Erlangung des Tokens wird als Autorisierungsfluss bezeichnet.

OAuth 1.0 wurde erstmals 2007 als Autorisierungsmethode für die damalige Twitter-Anwendungsprogrammschnittstelle (API) veröffentlicht. Im Jahr 2010 veröffentlichte die IETF OAuth Working Group den ersten Entwurf des OAuth 2.0-Protokolls. Wie das ursprüngliche OAuth-Protokoll bietet OAuth 2.0 Benutzern die Möglichkeit, Anwendungen von Drittanbietern Zugriff auf Webressourcen zu gewähren, ohne dass sie ein Passwort angeben müssen. Es handelt sich jedoch um ein völlig neues Protokoll, das nicht rückwärtskompatibel mit OAuth 1.0 ist. Zu den aktualisierten Funktionen gehören ein neuer Autorisierungscodefluss zur Anpassung an mobile Anwendungen, vereinfachte Signaturen und kurzlebige Token mit langlebigen Autorisierungen.

Wie funktioniert OAuth 2.0?

Der Autorisierungsfluss in einer typischen OAuth 2.0-Implementierung ist ein sechsstufiger Prozess. Im folgenden Beispiel muss eine Anwendung zur Erstellung eines Online-Kalenders in der Lage sein, auf die Fotos eines Benutzers zuzugreifen, die in dessen Google Drive gespeichert sind:

1. Die Anwendung zur Erstellung des Kalenders (der Client) fordert die Genehmigung für den Zugriff auf geschützte Ressourcen, in diesem Fall Bilddateien, an, die dem Benutzer (Eigentümer der Ressource) gehören, indem sie den Benutzer an den Autorisierungsendpunkt weiterleitet.
2. Der Ressourceneigentümer authentifiziert und autorisiert die Ressourcenzugriffsanfrage der Anwendung, und der Autorisierungsendpunkt gibt eine Autorisierungserlaubnis an den Client zurück. Das OAuth 2.0-Protokoll definiert vier Arten von Berechtigungen: Autorisierungscode, Client Credentials, Gerätecode und Refresh Token.
3. Der Client fordert dann ein Zugriffs-Token vom Autorisierungsserver an, indem er die vom Autorisierungsendpunkt zurückgegebene Autorisierungserlaubnis zusammen mit der Authentifizierung seiner eigenen Identität an den Token-Endpunkt übermittelt. Ein Token-Endpunkt ist eine URL wie https://your_domain/oauth2/token.
4. Wenn die Client-Identität authentifiziert und die Autorisierungsgewährung gültig ist, gibt der Autorisierungsserver oder Authentifizierungsanbieter - in diesem Fall der Autorisierungsserver von Google - ein Zugriffs-Token an den Client aus.
5. Der Client kann nun die geschützten Ressourcen vom Ressourcenserver - in diesem Beispiel Google Drive - anfordern, indem er das Zugriffstoken zur Authentifizierung vorlegt.
6. Wenn das Zugriffstoken gültig ist, gibt der Ressourcenserver die angeforderten Ressourcen an die Anwendung zur Kalendererstellung (Client) zurück.

Nun kann die Anwendung zur Kalendererstellung auf die Fotos des Benutzers zugreifen und diese importieren, um einen Kalender zu erstellen. Je nach Art, der in Schritt zwei erteilten Genehmigung kann sich der Genehmigungsablauf leicht unterscheiden. Er folgt jedoch weitgehend diesen Kernschritten.

Beispiele für OAuth

OAuth wird häufig verwendet, um Benutzeranmeldedaten zu konsolidieren und den Anmeldeprozess für Benutzer zu rationalisieren, so dass sie beim Zugriff auf einen Online-Dienst nicht erneut Informationen eingeben müssen, die sie bereits in vielen ihrer anderen Online-Konten haben.

OAuth ist die zugrundeliegende Technologie, die für die Website-Authentifizierung von Websites verwendet wird, die es Nutzern ermöglichen, sich über ihr Konto bei einer anderen Website wie LinkedIn, Google oder GitHub zu registrieren oder anzumelden. Klickt ein Nutzer beispielsweise auf die Facebook-Anmeldeoption, wenn er sich auf einer anderen Website anmeldet, wird er von Facebook authentifiziert, und die ursprüngliche Website meldet ihn mit der von Facebook erhaltenen Genehmigung an.

OAuth kann auch verwendet werden, um einem Webdienst den Zugriff auf geschützte Ressourcen zu ermöglichen, die bei einem anderen Dienst gespeichert sind - wie im obigen Kalenderbeispiel - oder für die E-Mail-Authentifizierung, so dass ein Dienst E-Mails von einem Konto eines Drittanbieters wie Google Mail senden und empfangen kann, was bedeutet, dass ein Benutzer zwei verschiedene Dienste mit nur einer Anmeldung nutzen kann. Beispielsweise kann das Strava-Konto eines Benutzers auf sein Garmin Connect-Konto zugreifen, ohne dass er seinen Garmin-Benutzernamen und sein Kennwort mit Strava teilen muss. OAuth wird auch häufig verwendet, wenn eine Webanwendung Zugriff auf das Mikrofon oder die Kamera eines Geräts anfordert.

OAuth 1.0 vs. OAuth 2.0

OAuth 2.0 ist eine vollständige Neufassung von OAuth 1.0 und verwendet eine andere Terminologie und andere Begriffe. Die Begriffe Consumer, Service Provider und User von OAuth 1.0 werden in OAuth 2.0 zu Client, Authorization Server, Resource Server und Resource Owner. OAuth 1.0 trennt nicht ausdrücklich die Rollen von Ressourcenserver und Autorisierungsserver.

Zu den wichtigsten funktionalen Änderungen zwischen den beiden Versionen gehören eine bessere Aufgabentrennung, eine einfachere Client-seitige Entwicklung und eine höhere Benutzerfreundlichkeit. OAuth 2.0 bietet spezifische Autorisierungsabläufe für Webanwendungen, Desktop-Anwendungen, Mobiltelefone und nicht browserbasierte Anwendungen wie API-basierte Dienste.

Desktop- und mobile Anwendungen müssen den Benutzer nicht mehr anweisen, seinen Browser zum gewünschten Dienst zu öffnen, sich beim Dienst zu authentifizieren und das Token vom Dienst zurück in die Anwendung zu kopieren. Bei OAuth 2.0 muss weder der Client noch der Server eine Signatur zur Sicherung der Nachrichten erstellen. Die Sicherheit wird durch TLS/SSL (HTTPS) für die gesamte Kommunikation gewährleistet. OAuth 2.0-Zugangstoken sind „kurzlebig“ - von sitzungsbasiert bis zu ein paar Wochen -, verwenden aber Refresh-Token, um ein neues Zugangstoken zu erhalten, anstatt dass der Benutzer den gesamten Prozess zur erneuten Autorisierung der Anwendung erneut durchlaufen muss.

SAML vs. OAuth

Während OAuth ein Autorisierungsprotokoll ist, ist SAML (Security Assertion Markup Language) ein föderiertes Authentifizierungsprotokoll, das auf die Sicherheit von Unternehmen ausgerichtet ist. Es ist für die Verwendung in Single-Sign-On-Szenarien (SSO) konzipiert, die es einem Benutzer ermöglichen, sich mit einer einzigen ID und einem einzigen Passwort bei verschiedenen verbundenen Systemen und Diensten anzumelden.

Es implementiert eine sichere Methode zur Weitergabe von Benutzerauthentifizierungen und -autorisierungen zwischen einem Identitätsanbieter (IdP) und einem Dienstanbieter (SP). Beispiele für Identitätsanbieter sind Microsoft Active Directory und Azure, da sie die Anmeldeinformationen eines Benutzers authentifizieren und die Benutzerberechtigung an den Dienstanbieter zurückgeben, damit der Benutzer auf die Anwendung zugreifen kann. Salesforce und andere CRM-Lösungen sind in der Regel Service Provider, da sie die Autorisierung vom entsprechenden Identitätsprovider für die Benutzerauthentifizierung anfordern. Die SAML-Autorisierung kann dem Service Provider auch mitteilen, welche Zugriffsebene er dem authentifizierten Benutzer gewähren soll. SAML ist stärker benutzerorientiert als OAuth, das eher anwendungsorientiert ist, da sich ein Benutzer im Allgemeinen bei jedem einzelnen Dienst authentifiziert und die Anwendung eine 1:1 -Zuordnung zu einem IdP hat.

Obwohl SAML XML und OAuth JSON für die Übermittlung von Nachrichten verwendet, liegt der eigentliche Unterschied darin, dass OAuth in großem Umfang API-Aufrufe verwendet, während SAML Sitzungs-Cookies einsetzt. Dies ist für den Zugriff auf bestimmte Dienste während des Arbeitstages in Ordnung, aber für mobile Anwendungen, Spielkonsolen und IoT-Geräte weit weniger benutzerfreundlich. Die OAuth 2.0-Client-Registrierung ist in der Regel eine einmalige Aufgabe. Einmal registriert, bleibt die Registrierung gültig, es sei denn, die OAuth-Client-Registrierung wird widerrufen.

OAuth vs. OpenID

OpenID Connect ist eine Identitätsschicht, die auf dem OAuth-2.0-Protokoll aufbaut. Während OAuth 2.0 einem Nutzer eines Dienstes erlaubt, einer Drittanbieter-Anwendung den Zugriff auf seine bei dem Dienst gehosteten Daten zu gestatten, ohne der Anwendung seine Anmeldeinformationen zu offenbaren, erlaubt OpenID Connect einer Drittanbieter-Anwendung, die Identitätsinformationen eines Nutzers zu erhalten, die von einem Dienst verwaltet werden. Diese Funktionalität erleichtert es Entwicklern, ihre Nutzer über Websites und Anwendungen hinweg zu authentifizieren, ohne deren Passwörter besitzen und verwalten zu müssen.

Viele Anwendungen verwenden OAuth 2.0 sowohl für die Authentifizierung als auch für die Autorisierung, aber technisch gesehen ist es nur für die delegierte Autorisierung spezialisiert, nicht für die Authentifizierung. In RFC 6749 Abschnitt 3.1. heißt es: Der Autorisierungsendpunkt wird verwendet, um mit dem Ressourceneigentümer zu interagieren und eine Autorisierungsgenehmigung zu erhalten. Der Autorisierungsserver MUSS zunächst die Identität des Ressourceneigentümers verifizieren. Die Art und Weise, wie der Autorisierungsserver den Ressourceneigentümer authentifiziert (zum Beispiel Anmeldung mit Benutzername und Passwort, Sitzungscookies), liegt außerhalb des Anwendungsbereichs dieser Spezifikation.

Obwohl es viele Bibliotheken und Dienste gibt, die OAuth 2.0 für die Authentifizierung verwenden, ist die Authentifizierung, die nur auf OAuth basiert, nicht sicher und sollte mit dem OpenID Connect-Standard kombiniert werden, wenn Entwickler ein sicheres „Social Login“ erstellen möchten, das sowohl Authentifizierung als auch Autorisierung kombiniert.