Autorisierungsdienste mit OAuth
Seite 2: Szenarien und Spezifikationen
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.
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.
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.
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.
- 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.
