Sichere Interaktion mit Service Providern
OAuth -Sichere Interaktion mit Service Providern
OAuth ist ein offenes Protokoll, das eine standardisierte, sichere API-Autorisierung für Desktop-, Web- und Mobile-Applikationen erlaubt.
Ein Beispiel vorab:
Karin ist Journalistin und möchte für eine Recherche zum Thema „Global Warming“ Twitter benutzen. Sie macht eine Suche in Twitter und erhält interessante Ergebnisse. Nun würde sie gerne über einen längeren Zeitraum beobachten, welche Tweets sich zu diesem Thema ansammeln.
Anschließend möchte sie die Tweets analysieren. Folgende Fragestellungen schweben ihr z.B. vor: Gibt es vorwiegend skeptische Tweets zu dem Thema? Gibt es bestimmte Benutzer oder Gruppen, die sich intensiv mit dem Thema befassen?
Karin entdeckt im Internet eine Applikation Tweet-Analytics 1.0 von der Firma Tweet-Experts. Diese bietet das Monitoring von Suchbegriffen und umfassende Analysemöglichkeiten an. Karin ist begeistert. Als die Applikation aber von ihr verlangt, ihren Twitter Benutzernamen und ihr Passwort einzugeben, kommt ihr das komisch vor …
Problemstellung
Es ist natürlich verständlich, dass Karin ihre Twitter Zugangsdaten nicht irgend einer Applikation zur Verfügung stellen möchte. Wer weiß, was die Applikation damit anstellt und wem sie die Zugangsdaten weitergibt.
Die Applikation Tweet-Analytics 1.0 möchte in Vertretung von Karin wiederholt Suchabfragen bei Twitter durchführen. Gibt es eine bessere Möglichkeit, als dafür direkt Karins Zugangsdaten zu verwenden?
Das ist eine der Problemstellungen, für die OAuth eine Lösung bietet.
OAuth Rollen und Interaktionen
Um für obige Problemstellung die Lösung von OAuth zu skizzieren, sollen zunächst einige Rollen anhand unseres Beispiels definiert werden:
Service Provider: im obigen Beispiel Twitter, weitere Service Provider sind z.B. Facebook, LinkedIn, DropBox, GoogleDrive, usw.
User: jemand, der einen Account bei einem Service Provider hat, in unserem Beispiel Karin, die einen Account bei Twitter hat.
Consumer: eine Applikation, die im Namen des Users auf Daten des Service Providers zugreift, im Beispiel ist das die Applikation Tweet-Analytics
Consumer Developer: die Person oder Organisation, die einen Consumer implementiert, im Beispiel die Firma Tweet-Experts
Auth spezifiziert eine Reihe von Interaktionen zwischen diesen Rollen, um eine erhöhte Sicherheit und Transparenz beim Datenaustausch herzustellen.
Registrierung – Consumer Key, Consumer Secret
Der Consumer Developer muss den Consumer beim Service Provider registrieren. Bei der Registrierung kann detailgenau konfiguriert werden, auf welche Daten der Consumer Zugriff hat. So ist es letztendlich für den User transparent, was mit seinen Daten geschieht. Nach erfolgreicher Registrierung erhält der Consumer zwei Zeichenfolgen – einen Consumer Key und ein Consumer Secret. Diese Zeichenfolgen sind vom Consumer sicher zu verwahren.
Autorisierter Zugriff – Access Token, Token Secret
Der User möchte nun einem registrierten Consumer autorisierten Zugriff auf Dienste des Service Providers ermöglichen. Er initiiert eine Interaktion mit dem Consumer. Der Consumer wendet sich darauf hin an den Service Provider und erhält von diesem einen Request Token.
Der Request Token ist für kurze Zeit gültig. Der Consumer verwendet ihn, um eine Interaktion zwischen User und Service Provider einzuleiten. In dieser Interaktion bestätigt der User mit seinen Zugangsdaten seine Identität beim Service Provider und autorisiert den Zugriff des Consumers.
Nach erfolgter Autorisierung verfällt der Request Token. Der Service Provider wendet sich nun an den Consumer und übergibt diesem zwei Zeichenketten, einen Access Token und ein Token Secret. Diese beiden Zeichenketten befähigen den Consumer, im Namen des Users auf Dienste des Service Providers zuzugreifen. Der Consumer muss diese Zeichenketten sicher verwahren. Bei jedem Zugriff schickt der Consumer alle 4 Zeichenketten mit, nämlich den Consumer Key, das Consumer Secret, den Access Token und das Token Secret.
Auf diese Art ist Transparenz für alle beteiligten Parteien hergestellt. Der Service Provider weiß, wer in welchem Namen auf seine Dienste zugreift. Der User weiß, welche Consumer er autorisiert hat und der Consumer kann im Namen des Users agieren, ohne dessen Zugangsdaten zu kennen.
Damit ist die Problemstellung aus dem obigem Beispiel gelöst.
Beispiel – Fortsetzung
Twitter und andere namhafte Service Provider implementieren die OAuth Spezifikation und ermöglichen die beschriebenen Interaktionen.
Die Firma Tweet-Experts plant, für die nächste Version ihres Produkts Tweet-Analytics 2.0 ebenso die OAuth Spezifikation zu implementieren. Schliesslich soll die Journalistin Karin die Applikation vertrauensvoll verwenden können.
Die Tweet-Experts registrieren also ihre Applikation Twitter-Analytics bei Twitter und erhalten darauf hin den Consumer Key „123“ und das Consumer Secret „456“. Sie speichern beide Zeichenfolgen verschlüsselt in der anwendungseigenen Datenbank.
Abbildung 1: Registrierung (ck=Consumer Key, cs=Consumer Secret)
Karin gibt Tweet-Analytics in Version 2.0 noch einmal eine Chance. Sie macht einen Suchauftrag zum Thema „Global Warming“. Darauf hin wird sie von Tweet-Analytics an Twitter weitergeleitet und dort gefragt, ob sie die Applikation für den Zugriff in ihrem Namen berechtigt. Zur Bestätigung gibt Karin ihre Twitter Zugangsdaten (bei Twitter!) ein und klickt auf „autorisieren“. Daraufhin erhält Tweet-Analytics von Twitter den Access Token „abc“ und das Token Secret „def“ und speichert diese verschlüsselt ab.
Autorisierter Zugriff
Abbildung 2: Autorisierter Zugriff (ck=Consumer Key, cs=Consumer Secret, at=Access Token, ts=Token Secret)
Ab diesem Zeitpunkt kann Tweet-Analytics mit den erhaltenen Zeichenfolgen (123, 456, abc, def) die Autorisierung beweisen und in Karins Namen die gewünschte Suche durchführen. Karin kann die Analysemöglichkeiten von Tweet-Analytics nutzen, ohne ihre Twitter Zugangsdaten (jemand anderem als Twitter) preiszugeben.
OAuth in Tomo
Tomo implementiert die OAuth Spezifikation und nimmt in diesem Zusammenhang die Consumer Rolle ein. Bei zahlreichen Service Providern (Twitter, Facebook, LinkedIn, DropBox, usw.) ist Tomo als Anwendung registriert und bietet jeweils eigene ergänzende Services (ähnlich zu Tweet- Analytics) an. Unsere User können diese Services via OAuth nutzen.
