OAuth

OAuth-Logo ⓘ

OAuth (Open Authorization) ist der Name zweier verschiedener offener Protokolle, die eine standardisierte, sichere API-Autorisierung für Desktop-, Web- und Mobile-Anwendungen erlauben. OAuth 1.0 wurde ab 2006 entwickelt und 2007 veröffentlicht. OAuth 2.0, das sich grundlegend von OAuth 1.0 unterscheidet, wurde 2012 von der IETF als RFC 6749 und RFC 6750 veröffentlicht. ⓘ

Ein Endbenutzer (User oder Resource Owner) kann mit Hilfe dieses Protokolls einer Anwendung (Client oder Relying Party) den Zugriff auf seine Daten erlauben (Autorisierung), die von einem anderen Dienst (Resource Server) bereitgestellt werden, ohne geheime Details seiner Zugangsberechtigung (Authentifizierung) dem Client preiszugeben. Der Endbenutzer kann so Dritten gestatten, in seinem Namen einen Dienst zu benutzen. Typischerweise wird dabei die Übermittlung von Passwörtern an Dritte vermieden. ⓘ

Auf Basis von OAuth 2.0 wird OpenID Connect heute in vielen Internetdiensten auch zur Authentifizierung von Benutzern eingesetzt. ⓘ

OAuth ("Open Authorization") ist ein offener Standard für die Zugriffsdelegation, mit dem Internetnutzer Websites oder Anwendungen Zugriff auf ihre Informationen auf anderen Websites gewähren können, ohne ihnen die Passwörter zu geben. Dieser Mechanismus wird von Unternehmen wie Amazon, Google, Facebook, Microsoft und Twitter verwendet, um den Nutzern zu ermöglichen, Informationen über ihre Konten mit Anwendungen oder Websites von Drittanbietern zu teilen. ⓘ

Überblick

Im Allgemeinen bietet OAuth Clients einen "sicheren delegierten Zugriff" auf Serverressourcen im Namen eines Ressourcenbesitzers. Es spezifiziert ein Verfahren, mit dem Ressourcenbesitzer den Zugriff Dritter auf ihre Serverressourcen genehmigen können, ohne Anmeldedaten anzugeben. OAuth wurde speziell für das Hypertext Transfer Protocol (HTTP) entwickelt und ermöglicht es im Wesentlichen, dass ein Autorisierungsserver mit Zustimmung des Ressourceneigentümers Zugriffstoken an Drittanbieterclients ausstellt. Die dritte Partei verwendet dann das Zugriffstoken, um auf die geschützten Ressourcen zuzugreifen, die vom Ressourcenserver gehostet werden. OAuth 2.0 bietet insbesondere spezifische Autorisierungsabläufe für Webanwendungen, Desktop-Anwendungen, Mobiltelefone und intelligente Geräte. ⓘ

Ein hypothetischer Autorisierungsablauf, bei dem Anmeldeinformationen an eine Drittanbieteranwendung weitergegeben werden. Dies birgt viele Sicherheitsrisiken, die durch die Verwendung von OAuth-Autorisierungsflüssen verhindert werden können.
Ein Überblick über den Oauth 2.0-Fluss auf hoher Ebene. Die Anmeldedaten des Ressourceneigentümers werden nur auf dem Autorisierungsserver, nicht aber auf dem Client (z. B. der Drittanbieteranwendung) verwendet. ⓘ

Geschichte

Das OAuth-Logo, entworfen vom amerikanischen Blogger Chris Messina

OAuth begann im November 2006, als Blaine Cook die Twitter OpenID-Implementierung entwickelte. In der Zwischenzeit benötigte Ma.gnolia eine Lösung, um seinen Mitgliedern mit OpenIDs die Autorisierung von Dashboard-Widgets für den Zugriff auf ihren Dienst zu ermöglichen. Cook, Chris Messina und Larry Halff von Magnolia trafen sich mit David Recordon, um die Verwendung von OpenID mit den APIs von Twitter und Magnolia zu diskutieren, um die Authentifizierung zu delegieren. Sie kamen zu dem Schluss, dass es keine offenen Standards für die Delegation des API-Zugriffs gibt. ⓘ

Die OAuth-Diskussionsgruppe wurde im April 2007 für eine kleine Gruppe von Implementierern gegründet, um einen Entwurf für ein offenes Protokoll zu schreiben. DeWitt Clinton von Google erfuhr von dem OAuth-Projekt und bekundete sein Interesse, die Bemühungen zu unterstützen. Im Juli 2007 erstellte das Team eine erste Spezifikation. Eran Hammer schloss sich dem Team an und koordinierte die vielen OAuth-Beiträge zur Erstellung einer formelleren Spezifikation. Am 4. Dezember 2007 wurde der endgültige Entwurf von OAuth Core 1.0 veröffentlicht. ⓘ

Auf der 73. Sitzung der Internet Engineering Task Force (IETF) in Minneapolis im November 2008 wurde ein OAuth BoF abgehalten, um die Aufnahme des Protokolls in die IETF für weitere Standardisierungsarbeiten zu diskutieren. Die Veranstaltung war gut besucht und es gab eine breite Unterstützung für die formelle Gründung einer OAuth-Arbeitsgruppe innerhalb der IETF. ⓘ

Das OAuth 1.0-Protokoll wurde im April 2010 als RFC 5849, ein informativer Request for Comments, veröffentlicht. Seit dem 31. August 2010 sind alle Twitter-Anwendungen von Drittanbietern verpflichtet, OAuth zu verwenden. ⓘ

Das OAuth 2.0-Framework wurde unter Berücksichtigung zusätzlicher Anwendungsfälle und Erweiterungsanforderungen veröffentlicht, die von der breiteren IETF-Community gesammelt wurden. Obwohl OAuth 2.0 auf den Erfahrungen mit OAuth 1.0 aufbaut, ist es nicht rückwärtskompatibel mit OAuth 1.0. OAuth 2.0 wurde im Oktober 2012 als RFC 6749 und die Bearer Token Usage als RFC 6750 veröffentlicht, beides Standards im Rahmen von Requests for Comments. ⓘ

Das OAuth 2.1 Authorization Framework befindet sich im Entwurfsstadium und konsolidiert die Funktionalität in den RFCs OAuth 2.0, OAuth 2.0 for Native Apps, Proof Key for Code Exchange, OAuth 2.0 for Browser-Based Apps, OAuth Security Best Current und Bearer Token Usage. ⓘ

Sicherheitsprobleme

Sicherheit

Am 23. April 2009 wurde eine Sicherheitslücke im Protokoll von OAuth 1.0 aufgedeckt. Sie betraf den OAuth-Authentifizierungsablauf (auch bekannt als „Dreibeiniges OAuth“, englisch 3-legged OAuth) im OAuth Core 1.0 Abschnitt 6. ⓘ

Eran Hammer, ein bis dahin zentraler Redakteur der Spezifikation OAuth 2.0, verließ Ende Juli 2012 das Projekt, weil dessen Komplexität seiner Einschätzung nach von den meisten Softwareentwicklern kaum noch sicher implementierbar sei. ⓘ

OAuth 2.0

Im Januar 2013 veröffentlichte die Internet Engineering Task Force ein Bedrohungsmodell für OAuth 2.0. Unter den darin beschriebenen Bedrohungen befindet sich eine mit der Bezeichnung "Open Redirector"; Anfang 2014 wurde eine Variante dieser Bedrohung unter dem Namen "Covert Redirect" von Wang Jing beschrieben. ⓘ

OAuth 2.0 wurde mit Hilfe einer formalen Webprotokoll-Analyse untersucht. Diese Analyse ergab, dass in Konfigurationen mit mehreren Autorisierungsservern, von denen sich einer böswillig verhält, Clients verwirrt werden können, welcher Autorisierungsserver zu verwenden ist, und möglicherweise Geheimnisse an den böswilligen Autorisierungsserver weiterleiten (AS-Mix-Up-Angriff). Dies veranlasste die Erstellung eines neuen Internetentwurfs für die beste aktuelle Praxis, der einen neuen Sicherheitsstandard für OAuth 2.0 definieren soll. Unter der Annahme, dass ein Fix gegen den AS-Mix-Up-Angriff vorhanden ist, wurde die Sicherheit von OAuth 2.0 unter starken Angreifermodellen mittels formaler Analyse nachgewiesen. ⓘ

Eine Implementierung von OAuth 2.0 mit zahlreichen Sicherheitslücken wurde aufgedeckt. ⓘ

Im April und Mai 2017 wurden etwa eine Million Gmail-Nutzer (weniger als 0,1 % der Nutzer, Stand Mai 2017) Ziel eines OAuth-basierten Phishing-Angriffs, bei dem sie eine E-Mail erhielten, die vorgab, von einem Kollegen, Arbeitgeber oder Freund zu stammen, der ein Dokument auf Google Docs freigeben wollte. Diejenigen, die auf den Link in der E-Mail klickten, wurden angewiesen, sich anzumelden und einem potenziell bösartigen Drittanbieterprogramm namens "Google Apps" den Zugriff auf ihr "E-Mail-Konto, ihre Kontakte und Online-Dokumente" zu ermöglichen. Innerhalb von "ungefähr einer Stunde" wurde der Phishing-Angriff von Google gestoppt, das denjenigen, die "Google Apps" Zugriff auf ihre E-Mails gewährt hatten, riet, diesen Zugriff zu widerrufen und ihre Passwörter zu ändern. ⓘ

Im Entwurf von OAuth 2.1 wurde die Verwendung der PKCE-Erweiterung für native Anwendungen allen Arten von OAuth-Clients empfohlen, einschließlich Webanwendungen und anderen vertraulichen Clients, um zu verhindern, dass bösartige Browsererweiterungen OAuth-2.0-Code-Injection-Angriffe durchführen. ⓘ

Verwendet

Die Graph API von Facebook unterstützt nur OAuth 2.0. Google unterstützt OAuth 2.0 als den empfohlenen Autorisierungsmechanismus für alle seine APIs. Auch Microsoft unterstützt OAuth 2.0 für verschiedene APIs und seinen Azure Active Directory-Dienst, der zur Sicherung vieler APIs von Microsoft und Drittanbietern verwendet wird. ⓘ

OAuth kann als Autorisierungsmechanismus für den Zugriff auf gesicherte RSS/Atom-Feeds verwendet werden. Der Zugriff auf RSS/ATOM-Feeds, die eine Authentifizierung erfordern, war schon immer ein Problem. So konnte beispielsweise auf einen RSS-Feed von einer gesicherten Google-Site nicht mit Google Reader zugegriffen werden. Stattdessen musste der RSS-Client mit Hilfe von OAuth autorisiert werden, um auf den Feed von der Google-Website zuzugreifen. ⓘ

OAuth und andere Standards

OAuth ist ein Dienst, der OpenID ergänzt und sich von diesem unterscheidet. OAuth hat nichts mit OATH zu tun, bei dem es sich um eine Referenzarchitektur für die Authentifizierung und nicht um einen Standard für die Autorisierung handelt. Allerdings ist OAuth direkt mit OpenID Connect (OIDC) verbunden, da OIDC eine Authentifizierungsschicht ist, die auf OAuth 2.0 aufbaut. OAuth hat auch nichts mit XACML zu tun, das ein Standard für Autorisierungsrichtlinien ist. OAuth kann in Verbindung mit XACML verwendet werden, wobei OAuth für die Zustimmung zum Eigentum und die Delegation des Zugriffs verwendet wird, während XACML zur Definition der Autorisierungsrichtlinien verwendet wird (z. B. können Manager Dokumente in ihrer Region einsehen). ⓘ

OpenID vs. Pseudo-Authentifizierung mit OAuth

OAuth ist ein Autorisierungsprotokoll und kein Authentifizierungsprotokoll. Die alleinige Verwendung von OAuth als Authentifizierungsmethode kann als Pseudo-Authentifizierung bezeichnet werden. Die folgenden Diagramme verdeutlichen die Unterschiede zwischen der Verwendung von OpenID (speziell als Authentifizierungsprotokoll konzipiert) und OAuth zur Autorisierung. ⓘ

Der Kommunikationsfluss in beiden Prozessen ist ähnlich:

(Nicht abgebildet) Der Benutzer fordert eine Ressourcen- oder Site-Anmeldung von der Anwendung an.
Die Website stellt fest, dass der Benutzer nicht authentifiziert ist. Sie formuliert eine Anfrage an den Identitätsanbieter, kodiert sie und sendet sie als Teil einer Umleitungs-URL an den Benutzer.
Der Browser des Benutzers stellt eine Anfrage an die Umleitungs-URL für den Identitätsanbieter, einschließlich der Anfrage der Anwendung
Falls erforderlich, authentifiziert der Identitätsanbieter den Benutzer (indem er ihn z. B. nach seinem Benutzernamen und Kennwort fragt).
Sobald der Identitätsanbieter sich vergewissert hat, dass der Benutzer ausreichend authentifiziert ist, verarbeitet er die Anfrage der Anwendung, formuliert eine Antwort und sendet diese zusammen mit einer Umleitungs-URL an den Benutzer zurück zur Anwendung.
Der Browser des Benutzers fordert die Umleitungs-URL an, die zur Anwendung zurückführt, einschließlich der Antwort des Identitätsanbieters.
Die Anwendung dekodiert die Antwort des Identitätsanbieters und fährt entsprechend fort.
(nur OAuth) Die Antwort enthält ein Zugriffstoken, mit dem die Anwendung im Namen des Benutzers direkten Zugang zu den Diensten des Identitätsanbieters erhalten kann. ⓘ

Der entscheidende Unterschied besteht darin, dass im Anwendungsfall der OpenID-Authentifizierung die Antwort des Identitätsanbieters eine Identitätsbestätigung ist, während im Anwendungsfall der OAuth-Autorisierung der Identitätsanbieter auch ein API-Anbieter ist und die Antwort des Identitätsanbieters ein Zugriffstoken ist, das der Anwendung im Namen des Benutzers fortlaufend Zugriff auf einige der APIs des Identitätsanbieters gewährt. Das Zugriffstoken fungiert als eine Art "Valet Key", den die Anwendung ihren Anfragen an den Identitätsanbieter beifügen kann, um zu beweisen, dass sie die Erlaubnis des Benutzers hat, auf diese APIs zuzugreifen. ⓘ

Da der Identitätsanbieter in der Regel (aber nicht immer) den Benutzer als Teil des Prozesses der Gewährung eines OAuth-Zugriffstokens authentifiziert, ist es verlockend, eine erfolgreiche OAuth-Zugriffstoken-Anfrage als eine Authentifizierungsmethode selbst zu betrachten. Da OAuth jedoch nicht für diesen Anwendungsfall konzipiert wurde, kann diese Annahme zu erheblichen Sicherheitsmängeln führen. ⓘ

OAuth und XACML

XACML ist ein richtlinien- und attributbasiertes Autorisierungssystem für die Zugriffskontrolle. Es bietet:

Eine Zugriffskontrollarchitektur.
Eine Policy-Sprache, mit der eine breite Palette von Zugriffskontrollrichtlinien ausgedrückt werden kann, einschließlich Richtlinien, die über OAuth abgewickelte/definierte Einwilligungen verwenden können.
Ein Anfrage/Antwort-Schema zum Senden und Empfangen von Autorisierungsanfragen.

XACML und OAuth können kombiniert werden, um einen umfassenderen Ansatz für die Autorisierung zu liefern. OAuth bietet keine Policy-Sprache, mit der Zugriffskontrollrichtlinien definiert werden können. XACML kann für seine Policy-Sprache verwendet werden. ⓘ

Während sich OAuth auf den delegierten Zugriff (ich, der Benutzer, gewähre Twitter Zugriff auf meine Facebook-Pinnwand) und die identitätszentrierte Autorisierung konzentriert, verfolgt XACML einen attributbasierten Ansatz, der Attribute des Benutzers, der Aktion, der Ressource und des Kontexts (wer, was, wo, wann, wie) berücksichtigen kann. Mit XACML ist es möglich, Richtlinien wie folgt zu definieren

Manager können Dokumente in ihrer Abteilung einsehen
Manager können Dokumente, die sie besitzen, im Entwurfsmodus bearbeiten ⓘ

XACML bietet eine feinkörnigere Zugriffskontrolle als OAuth. OAuth ist in seiner Granularität auf die grobe Funktionalität (die Scopes) beschränkt, die der Zieldienst zur Verfügung stellt. Daher ist es oft sinnvoll, OAuth und XACML miteinander zu kombinieren, wobei OAuth den Anwendungsfall des delegierten Zugriffs und die Zustimmungsverwaltung bereitstellt und XACML die Autorisierungsrichtlinien, die auf die Anwendungen, Prozesse und Daten einwirken. ⓘ

Schließlich kann XACML transparent über mehrere Stapel hinweg arbeiten (APIs, Web SSO, ESBs, selbst entwickelte Anwendungen, Datenbanken usw.). OAuth konzentriert sich ausschließlich auf HTTP-basierte Anwendungen. ⓘ

Kontroverse

Eran Hammer trat von seiner Rolle als Hauptautor des OAuth 2.0-Projekts zurück, zog sich aus der IETF-Arbeitsgruppe zurück und entfernte im Juli 2012 seinen Namen aus der Spezifikation. Als Grund für seinen Rücktritt nannte Hammer einen Konflikt zwischen Web- und Unternehmenskulturen und merkte an, dass die IETF eine Gemeinschaft sei, in der es "nur um Unternehmensanwendungen" gehe und die "nicht in der Lage sei, einfach zu sein". "Was jetzt angeboten wird, ist eine Blaupause für ein Autorisierungsprotokoll", bemerkte er, "das den Weg des Unternehmens darstellt", was eine "ganz neue Grenze für den Verkauf von Beratungsdiensten und Integrationslösungen" bietet. Beim Vergleich von OAuth 2.0 mit OAuth 1.0 weist Hammer darauf hin, dass OAuth 2.0 "komplexer, weniger interoperabel, weniger nützlich, unvollständiger und vor allem weniger sicher" geworden ist. Er erklärt, wie die architektonischen Änderungen für 2.0 die Token von den Clients loslösten, alle Signaturen und Kryptographie auf Protokollebene entfernten und ablaufende Token hinzufügten (weil Token nicht widerrufen werden konnten), während sie die Verarbeitung der Autorisierung erschwerten. Zahlreiche Punkte wurden in der Spezifikation unbestimmt oder unbegrenzt gelassen, weil "wie es in der Natur dieser Arbeitsgruppe liegt, kein Thema zu klein ist, um daran hängen zu bleiben oder es jeder Implementierung zu überlassen, wie sie sich entscheidet." ⓘ

Auch David Recordon zog später seinen Namen aus nicht näher genannten Gründen aus den Spezifikationen zurück. Dick Hardt übernahm die Rolle des Herausgebers, und das Rahmenwerk wurde im Oktober 2012 veröffentlicht. ⓘ

David Harris, Autor des E-Mail-Clients Pegasus Mail, kritisierte OAuth 2.0 als "absolutes Hundefrühstück", das von den Entwicklern verlange, für jeden Dienst (Gmail, Microsoft Mail-Dienste usw.) eigene Module zu schreiben und sich speziell bei ihnen zu registrieren. ⓘ

Rollen

In OAuth 2.0 existieren vier Rollen:

Resource Owner: Eine Entität (User), die einem Dritten den Zugriff auf ihre geschützten Ressourcen gewähren kann. Diese Ressourcen werden durch den Resource Server bereitgestellt. Ist der Resource Owner eine Person, wird dieser als User bezeichnet.
Resource Server: Der Server (Dienst), auf dem die geschützten Ressourcen (Protected Resources) liegen. Er ist in der Lage, auf Basis von Access Tokens darauf Zugriff zu gewähren. Ein solcher Token repräsentiert die delegierte Autorisierung des Resource Owners.
Client: Eine Anwendung (Relying Party), die auf geschützte Ressourcen des Resource Owners zugreifen möchte, die vom Resource Server bereitgestellt werden. Der Client kann auf einem Server (Webanwendung), Desktop-PC, mobilen Gerät etc. ausgeführt werden.
Authorization Server: Der Server authentifiziert den Resource Owner und stellt Access-Tokens für den vom Resource Owner erlaubten Anwendungsbereich (Scope) aus. Authorization Server und Resource Server werden häufig zusammengelegt und gemeinsam betrieben. ⓘ

Token

OAuth 2.0 verwendet Tokens zur Autorisierung eines Zugriffs auf geschützte Ressourcen. Dadurch kann einem Client Zugriff auf geschützte Ressourcen gewährt werden, ohne die Zugangsdaten des Dienstes an den Client weitergeben zu müssen.

Access Token: Um auf geschützte Daten auf dem Resource Server zuzugreifen, muss ein Access Token vom Client als Repräsentation der Autorisierung übermittelt werden. Mittels des Parameters scope können die mit dem Access Token verbundenen Berechtigungen festgelegt werden. Zum einen kann der Client gewünschte Berechtigungen beim Authorization Server anfragen, zum anderen teilt dieser die gewährten Berechtigungen mit. Das Access Token hat eine zeitlich begrenzte Gültigkeit.
Refresh Token: Ein Refresh Token kann dazu verwendet werden, beim Authorization Server ein neues Access Token anzufragen, falls das Access Token abgelaufen oder ungültig geworden ist. Das Refresh Token hat ebenfalls eine zeitlich begrenzte Gültigkeit. Diese wird in der Regel höher gewählt als die des Access Tokens. Das Refresh Token wird wie das Access Token nach der Autorisierung durch den Resource Owner vom Authorization Server an den Client gesendet. Da das Refresh Token selbst schon die Autorisierung des Resource Owners repräsentiert, muss für diese Neuanfrage eines Access Tokens keine weitere Autorisierung des Resource Owners mehr eingeholt werden (RFC 6749 Kapitel 1.5).
Der Einsatz von Access Token und Refresh Token besitzt den Vorteil, dass die Lebensdauer des Access Tokens gering (wenige Minuten) gehalten werden kann und somit die Sicherheit des Protokolls erhöht wird, da der Resource Server keinen Zugriff auf das langlebige Refresh Token hat, weil jenes im Gegensatz zum Access Token nur zwischen Client und Authorization Server ausgetauscht wird. Würde der Resource Server die Autorisierung nur bei der ersten Anfrage überprüfen, würde ein Rechteentzug keine Folgen haben. Ein Zugriff auf Daten und Dienste beim Resource Server wäre dann für den Client weiterhin möglich. Da jedoch die Lebenszeit des Access-Tokens nur wenige Minuten beträgt, würde ein späteres Erlangen des Access Tokens durch einen Angreifer keine weitreichenden Folgen haben, da der Authorization Server die Zugriffsberechtigungen bei Neuausstellung eines Access Tokens auf Basis des Refresh Tokens überprüfen kann. ⓘ

Abstrakter OAuth-2.0-Protokollfluss

Protocol Flow von OAuth 2.0 ⓘ

Der Client fordert eine Autorisierung vom Resource Owner an. Diese Autorisierungsanforderung kann direkt erfolgen, wird aber bevorzugt indirekt über den Authorization Server durchgeführt.
Der Client erhält eine Autorisierungsgenehmigung vom Resource Owner. Die Autorisierung kann über einen der vier Autorisierungsgenehmigungsprozesse (authorisation grant types) erfolgen oder es wird ein erweiterter Genehmigungsprozess verwendet.
Der Client fordert ein Access Token vom Authorization Server an. Hierfür nutzt er die Autorisierungsgenehmigung vom Resource Owner.
Der Authorization Server authentisiert den Client (permission to ask) und prüft die Autorisierungsgenehmigung des Resource Owners. Ist diese erfolgreich, stellt er ein Access Token aus.
Der Client fragt die geschützten Daten beim Resource Server an. Zur Authentisierung benutzt er das Access Token.
Der Resource Server prüft das Access Token und stellt, wenn gültig, die gewünschten Daten zur Verfügung. ⓘ

Authorization Grant Types

Um unterschiedliche Anwendungsfälle optimal abdecken zu können, wurden vier Genehmigungsprozesse definiert (authorization code, implicit, resource owner password credentials, client credentials). Ferner wurde die Möglichkeit offengehalten, weitere Grant Types zu definieren. So wurde z. B. im RFC 7523 die Nutzung von JSON Web Tokens (JWT) und im RFC 7522 die von SAML 2.0 definiert. ⓘ

Anwendungsfall

Authorization Code Grant Flow ⓘ

Ein Benutzer (Resource Owner) hat bei einem Online-Server F für Fotos (Resource Server) ein Benutzerkonto und einige Bilder (Protected Resources) hinterlegt. Er möchte die Bilder auf einem Dienst D für Farbdrucke (Client) ausdrucken lassen. Hierzu soll der Dienst D Zugriff auf die Bilder des Benutzers auf dem Server F erhalten. Da es sich hierbei um einen anderen Dienst handelt, als solche, die der Server F eventuell zur Verfügung stellt, muss sich Dienst D beim Server F autorisieren, damit der Zugriff gewährt wird. Aus Sicherheitsgründen wäre es nicht sinnvoll, dass der Benutzer seine Zugangsdaten (Benutzername und Passwort) für den Server F an den Dienst D übermittelt, damit dieser sich mit den vertraulichen Zugangsdaten authentifiziert. Denn dadurch hätte Dienst D uneingeschränkten Zugang auf die Daten und Funktionen im Benutzerkonto beim Server F. Der weitere Zugriff für Dienst D könnte dann nur noch durch das Ändern des Passworts verhindert werden. ⓘ

In einem solchen Fall ermöglicht OAuth dem Dienst D den Zugriff auf bestimmte vom Benutzer freigegebene Daten, meist auch nur temporär, und dies ganz ohne Preisgabe der Zugangsdaten an Dienst D. ⓘ

Hierzu ist auf der Seite des Dienstes D ein Link platziert, welcher die Beschreibung „Fotos von Server F laden“ hat und den Vorgang initiiert. Bereits in diesem Link sind die Informationen über das Vorhaben von Dienst D kodiert. ⓘ

Der Protokollablauf nach OAuth 2.0 sieht in diesem Fall wie folgt aus:

Der Benutzer (Resource Owner) wird durch einen Link auf den Server F weiter geleitet, wo er sich anmelden muss (Autorisierungs-Anfrage, Authorization Request). Zusätzlich wird ihm angezeigt, welcher Dienst auf welche Daten zugreifen möchte (Schritte 1–6).
Der Benutzer stimmt durch einen entsprechenden Link zu (Autorisierungsgewährung, Authorization Grant), dass Dienst D auf seine Fotos zugreifen darf. Server F erstellt daraufhin einen Autorisierungs-Code und teilt diesen dem Dienst D mit. Parallel wird der Benutzer wieder auf die Seite des Dienstes D umgeleitet (Schritte 7–10).
Dienst D fragt nun Server F mit dem Autorisierungs-Code nach einem Access Token (Schritt 11).
Server F erstellt ein Access Token und übermittelt dieses an Dienst D (Schritt 12).
Dienst D kann nun auf die Fotos von Server F zugreifen, wobei er jedes Mal das Access Token mit übermittelt (Schritt 13).
Daraufhin liefert Server F die geschützten Fotos des Benutzers an Dienst D aus (Schritt 14). ⓘ

Die obigen Punkte 1–6 entsprechen den Punkten A–F in Abschnitt 1.2 „Protocol Flow“ des RFC 6749 bzw. dem oben dargestellten abstrakten OAuth-2.0-Protokollfluss. ⓘ

OAuth 2.0 und OpenID Connect

OpenID Connect 1.0 ist eine Identitätsschicht basierend auf OAuth 2.0. Es ermöglicht Clients, die Identität des Nutzers anhand der Authentifizierung durch einen Autorisierungsserver zu überprüfen. Ferner können weitere grundlegende Informationen über den Nutzer in einer interoperablen Form (REST) erlangt werden. ⓘ

OpenID Connect ermöglicht es Clients aller Art, einschließlich Web-basierter, mobiler und JavaScript-Clients, überhaupt Informationen über authentifizierte Sitzungen und Nutzer zu erhalten. Die Spezifikation ist erweiterbar um optionale Funktionen wie Verschlüsselung von Identitätsdaten, Finden von OpenID-Providern und Session-Management. OpenID Connect erweitert somit OAuth 2.0 um alle notwendigen Funktionen für ein personalisiertes Login und Single Sign-On. ⓘ