Anwendungsszenarien und Spezifikationen

Es gibt zwei typische Anwendungen für OAuth:

1. Szenario: OAuth mit Endnutzerszenarien (originale OAuth-Version oder dreibeiniger OAuth-Typ genannt):
Es ermöglicht eine Interaktion mit Endnutzern. Service-Provider, Konsument und Endnutzer stellen die drei Elemente dar, die diesen Typ ausmachen (daher die Bezeichnung "dreibeinig"). Er ist für Datenaustausch und Webservice-Aufrufe zwischen Webanwendungen mit der Zustimmung des Endnutzers gedacht. Das Beispiel "Bezahlung mit einer EC-Karte" gibt seine Workflow wieder. Abbildung 1 zeigt ein Interaktionsdiagramm des Protokolltyps.

Interaktion bei OAuth mit Endnutzerszenarien (Abb. 1)
2. Szenario: OAuth ohne Endnutzeraktivitäten (Basisversion, "phone home", "signed request" oder zweibeinige OAuth genannt):
Es geht ausschließlich um eine Maschine-zu-Maschine-Kommunikation, ohne Interaktion von Endnutzern (daher die Bezeichnung zweibeinig, da der Endnutzer entfällt). Bei diesem Typ ist keine Authentifizierung des Endnutzers nötig. Er wird per ID aus der Konsumentenanwendung erkannt und an den Service-Provider weitergegeben. Der Typ ist für einen sicheren Zugriff über Webservices gedacht. Abbildung 2 zeigt die Interaktion des Protokolls.

Interaktion bei OAuth ohne Endnutzerszenarien (Abb. 2)
Für den dreibeingen Typ existiert eine offizielle Spezifikation , für die es bereits eine Überarbeitung gibt (siehe unten "Sicherheitsproblem in OAuth"). Für den zweibeinigen Typ ist nur eine Draft-Spezifikation vorhanden. Sie nimmt jedoch eine wichtige Rolle ein, da REST-Webservices ohne Endnutzer-Interaktion von der Spezifikation profitieren. Zudem verwendet sie die Open-Social-Community intensiv.

Bevor eine Konsumenten-Anwendung auf einem Service-Provider zugreifen kann, ist sie zuvor beim ihm anzumelden. Service-Provider benötigen meistens folgende Daten: Name, Autor und URL der Anwendung. Anschließend erhält die Konsumenten-Applikation Konsumentenschlüssel und -geheimnis. Der Schlüssel wird während der gesamten Kommunikation zwischen Konsumenten und Providern innerhalb einer Anfrage mit angegeben. Damit kann ein Service-Provider die Konsumenten-Anwendung erkennen. Die wiederum verwendet das Geheimnis für das Signieren der Anfrage. Der Service-Provider erhält die Ergebnissignatur und überprüft sie darauf hinsichtlich ihrer Korrektheit. Das Diagramm aus Abbildung 3 stellt den Sachverhalt übersichtlich dar.

Konsumenten-Schlüssel und -Geheimnis (Abb. 3)

Detaillierte Interaktion bei OAuth mit Endnutzerszenarien (Abb. 4)

Das Aktivitätsdiagramm aus Abbildung 4 zeigt, wie die Interaktionen zwischen den Akteuren in der originalen OAuth-Version stattfinden. Im Prinzip handelt es sich um die Kommunikation zwischen Konsumenten, Service-Provider und Endnutzer. Bei der Originalversion finden folgende Schritte statt:

• Der Konsument fragt nach einem nicht bestätigtem Anfrage-Token des Service-Providers.
• Der Endnutzer bestätigt den Anfrage-Token mit einer Authentifizierung beispielsweise durch ein Login beim Service-Provider. Den bestätigten Token erhält darauf der Konsument mitgeteilt.
• Der Konsument tauscht das bestätigte Anfrage-Token mit einem Zugriffs-Token aus.
• Mit dem zuvor empfangenen Zugriffs-Token fragt der Konsument anschließend aus den privaten Ressourcen des Service-Providers heraus nach den Daten.
• Der Service-Provider antwortet mit den erfragten Daten.

Das zweibeinige OAuth lässt sich aus der Originalversion ableiten. Es gestaltet sich einfacher als die ursprüngliche Version, da keine Interaktion zwischen Endnutzer und Konsument sowie Service-Provider besteht. Die Interaktionen zum Endnutzer bei der oben beschriebenen dreibeinigen OAuth-Spezifikation sind hier einfach zu entfernen. Es gibt ausschließlich einen einzigen Token-Typ. Folgende Schritte sind beim zweibeinigen OAuth-Protokoll (keine Fehlerbehandlung) zu berücksichtigen.

• Der Konsument erfragt die Daten bei den privaten Ressourcen des Service-Providers.
• Der Service-Provider antwortet nach einer Überprüfung des Tokens mit den erfragten Daten.

Ein eindeutiger Unterschied zwischen OAuth und OpenID liegt darin, dass OpenID eine Autorisierung auf privaten Ressourcen nicht direkt unterstützt. Es geht bei OpenID ausschließlich um die Authentifizierung eines Endnutzers über einen URL. Im Gegensatz dazu muss OAuth keine Authentifizierung des Endnutzers direkt anbieten. Das kann beispielsweise OpenID erledigen. OAuth stellt ausschließlich einen Autorisierungs- und Datenaustausch-Meschanismus zur Verfügung. Eine ausführliche Erklärung über den Unterschied zwischen OAuth und OpenID findet man in Malcolm Tredinnicks "Explanation: The Difference Between OpenID and OAuth".