Flexible und sichere Internetdienste mit OAuth 2.0

Inhaltsverzeichnis

Persönliche Daten und Internetdienste werden von einer Vielzahl unterschiedlicher Geräte aus genutzt. Explosionsartig stieg in den letzten Jahren die mobile Nutzung, aber auch Spielkonsolen und Unterhaltungsgeräte sind zunehmend vernetzt. Gefragt sind Techniken zum sicheren Zugriff auf solche Daten. Das Protokoll OAuth 2.0 empfiehlt sich als grundlegender Baustein, da es die Implementierung flexibler und sicherer Internetdienste ermöglicht und dem Benutzer jederzeit die Kontrolle über seine Daten gibt.

Ein Internet-Produkt muss Kunden heute mehr bieten als den Zugriff auf ihre Inhalte über eine Webseite. Apps für unterschiedliche Smartphone-Plattformen sind selbstverständlich, und am besten können die Kunden ihre Inhalte, wie bei Google und Twitter, auch aus anderen Angeboten heraus nutzen. Diesen Anforderungen kommt typischerweise eine HTTP-API nach, die den Zugriff aus eigenen und den Anwendungen Dritter auf die Inhalte der Kunden erlaubt. Hierbei stellt sich die Kernfrage: Wie lässt sich eine solche API gegen Missbrauch absichern, ohne Kunden und Entwickler unnötig zu behindern? Das einfach zu verwendende Sicherheitsprotokoll OAuth 2.0 bietet hierfür passende Antworten, die zudem gute Gründe dafür liefern, warum Branchengrößen wie Google und Facebook darauf setzen.

Die Autoren dieses Artikels stellen das Protokoll auf Basis eigener Erfahrungen in Implementierung und Betrieb von OAuth-Diensten vor und geben einen Ausblick auf die weitere Entwicklung. Sie sind oder waren an der Entwicklung und dem Betrieb von Identity-Management-Diensten (IDM) für Privatkundenprodukte der Deutschen Telekom beteiligt (beispielsweise T-Entertain oder Telekom-Cloud). Der Konzern betreibt seit 2008 Token-basierte IDM-Dienste zur Absicherung von APIs und Apps. Die dabei gesammelten Erfahrungen hat er in die Entwicklung des OAuth-Standards bei der Internet Engineering Task Force (IETF) eingebracht.

Apps, Apps, Apps

Ein typischer Internetdienst benötigt heute ein Portal und eine Vielzahl von Apps für die Nutzung diverser Smartphone-Plattformen und PCs. Eine weitverbreitete Architektur zeigt die Abbildung 1. Die langlebigen Daten der Benutzer liegen in einer Cloud, die eine REST API für den Zugriff von den diversen Clients zur Verfügung stellt. Wie wird nun der Zugriff auf die Daten authentifiziert und autorisiert? Die naheliegende Antwort ist, Benutzername und Passwort mit jeder REST-Anfrage mitzusenden.

Das hat aber diverse Nachteile: Die Prüfung des Passworts und die Abfrage der Benutzerberechtigungen müssen mit jedem Aufruf erfolgen. Das erhöht insbesondere in verteilten Umgebungen die Laufzeit jedes einzelnen Aufrufs. Langfristig viel schwerwiegender ist allerdings, dass die API an bestimmte Benutzer-Credentials und damit auch an einen bestimmten Zugriffskanal gebunden wird.

Wenn zum Beispiel ein Dienst in Fernsehgeräte integriert werden soll, stellt man schnell fest, dass Benutzername und Passwort für die Eingabe mit einer Fernbedienung ungeeignet sind. Eine PIN wäre vielleicht besser, oder man wählt einen sogenannten Split-Screen-Ansatz, bei dem die Authentifizierung auf einem anderen Gerät durchgeführt wird. Jede Änderung an der Authentifizierung würde bei der direkten Einbindung von Benutzername und Passwort in die Signatur der API einen Umbau der API und damit Mehrkosten und Zeitverlust nach sich ziehen. Viel schöner wäre doch, wenn man diese Details aus dem Design der API heraushalten könnte.

OAuth 2.0 bietet durch die Nutzung sogenannter Access Tokens ein Mittel an, um die Implementierung einer API von der eigentlichen Authentifizierung des Benutzers und der Autorisierung des Zugriffs zu trennen.

Dritte und Passwörter

Eine weitere Herausforderung ergibt sich bei der Nutzung von Daten bei einem Dienstanbieter im Kontext eines anderen. Als Beispiel könnte man sich vorstellen, dass ein Benutzer sein Adressbuch bei einem E-Mail-Anbieter auf einer Fotoseite verwenden möchte, um seinen Freunden Einladungen zuzusenden. Für den E-Mail-Anbieter ist das Szenario verlockend, da es die Relevanz der bei ihm verwalteten Daten und damit die Bindung des Benutzers an seinen Dienst erhöht. Gleichzeitig entstehen aber Sicherheitsrisiken. Denn wie sichert er den Zugriff auf die Adressdaten ab?

Typischerweise würde die Fotoseite den Benutzer nach seinen Credentials beim E-Mail- Anbieter fragen und diese dann für den Abruf der Daten benutzen (siehe Abb. 2). Dadurch ergibt sich das grundsätzliche Problem, dass eine fremde Seite das Passwort des Benutzers verarbeitet. Selbst wenn man davon ausgeht, dass die Fotoseite sorgsam mit dem Passwort umgeht und es insbesondere nicht speichert (was ja für Folgezugriffe praktisch wäre), kann es einem Angreifer in die Hände fallen. Dazu reicht es zum Beispiel aus, unabsichtlich Passwörter in Logfiles zu schreiben.

Dieses sogenannte "Password Anti-Pattern" war ein wichtiger Treiber hinter der Entwicklung von OAuth. Das Protokoll stellt sicher, dass immer der jeweilige Dienstanbieter die Benutzer-Credentials prüft. Des Weiteren garantiert er, dass die Identität des Benutzers nicht bekannt gegeben wird – es sei denn, der Benutzer wünscht das explizit.

Nutzer im Mittelpunkt

Ende 2009 begannen die Arbeiten an der OAuth-Version 2.0. Basis waren die Erfahrungen mit OAuth 1.0a und anbieterspezifischen Techniken wie Googles ClientLogin und AuthSub. Ziel war es, ein Protokoll zu schaffen, das von kleinen Installationen mit einem einzigen Dienst bis hin zu großen mit vielen unterschiedlichen Diensten skaliert und dabei so einfach zu benutzen ist, dass es jeder Entwickler – und nicht nur Sicherheitsexperten – implementieren und nutzen kann.

Die Einfachheit wurde durch einen vollständigen Verzicht auf digitale Signaturen innerhalb des Protokolls erreicht. Seine Sicherheit beruht vielmehr auf der konsequenten Verwendung von HTTPS, Zufallswerten und der Einmalnutzung bestimmter Parameter. Die Skalierbarkeit hat ein ganzes Paket an Maßnahmen verbessert. Zum einen ermöglicht der konsequente Einsatz von HTTPS den Verzicht auf Nonces (einzelne Zahlen- oder Buchstabenkombinationen, die nach einmaliger Verwendung verworfen werden) zur Vermeidung von Replay-Angriffen. Damit lassen sich serverseitige Implementierungen komplett zustandslos realisieren. Des Weiteren wurde das Protokoll nachhaltig modularisiert und lässt jetzt für das Design konkreter Implementierungen weitaus mehr Freiraum als die Version 1.0. Damit ist es sowohl für die Absicherung einfacher Dienste als auch für große Installationen mit vielen Diensten geeignet.

Abbildung 3 zeigt die Entitäten des OAuth-2.0-Protokolls und den abstrakten Protokollablauf. Das grundlegende Prinzip von OAuth ist die Benutzerkontrolle. Im Mittelpunkt steht der Schutz von Ressourcen eines Benutzers, zum Beispiel Dokumenten oder Adressbucheinträgen, vor unbefugtem Zugriff. Daher werden Benutzer als Resource Owner bezeichnet. Die Ressourcen verwaltet wiederum ein Resource Server. Von ihm erwartet man, dass er nur vom jeweiligen Benutzer autorisierte Zugriffe akzeptiert und durchführt. Die Autorisierung repräsentieren Access Tokens, die ein vertrauenswürdiger Authorization Server im Namen des Benutzers ausstellt. Als Voraussetzung authentifiziert der Authorization Server den Benutzer und holt dessen Autorisierung für die Durchführung des Zugriffs ein. Als Client bezeichnet man jede Anwendung, die im Auftrag des Benutzers auf geschützte Ressourcen desselben zugreift.

Der Client erhält nur Zugriff auf die Daten des Benutzers, wenn dieser vorher zugestimmt hat. Hierzu sendet der Client einen Authorization Request (1) an den Resource Owner. Das kann bedeuten, dass der Client den Benutzer direkt nach Benutzername und Passwort fragt. Es kann sich aber auch um eine Anfrage handeln, die via Browser-Weiterleitung über den Authorization Server als Mittler durchgeführt wird. Wenn der Benutzer dem Zugriff zustimmt, erhält der Client einen korrespondierenden (2) Authorization Grant ausgehändigt. Abbildung 4 zeigt beispielhaft einen Dialog für eine solche Zustimmung. Den Grant sendet der Client an den Authorization Server (3), der im Gegenzug ein Access Token ausstellt (4). Dieses verwendet der Client dann für die Autorisierung von Aufrufen beim Resource Server (5..n).

Das Access Token erlaubt es dem Resource Server festzustellen, im Namen welches Benutzers der Client agiert und welche Rechte der Benutzer an die Anwendung delegiert hat. Diese Tokens haben eine begrenzte Gültigkeit. Ein neues Access Token kann der Client zum einen durch erneute Rückfrage mit dem Benutzer erlangen, zum anderen lässt sich ein sogenanntes Refresh Token verwenden, welches das Abfragen eines neuen Access Token ohne Benutzerinteraktion ermöglicht. Ein Refresh Token hat eine wesentlich längere Lebenszeit als ein Access Token, lässt sich aber jederzeit vom Benutzer zurückziehen.

OAuth-Browser-Flow

Das Vorgehen im OAuth-Browser-Flow

Konzeptionell trennt OAuth 2.0 das Erlangen eines Access Token und dessen Verwendung strikt. Konsequenterweise sind beide Aspekte in unterschiedlichen Spezifikationen, der Kern-Spezifikation und dem neuen HTTP-Autorisierungsschema Bearer, definiert. Die erste definiert diverse Wege zum Erlangen von Token, die sogenannten Grant Types. Jeder Grant Type ist auf bestimmte Anwendungsfälle optimiert. Die Interaktion des Clients mit der API erfolgt unabhängig hiervon immer auf die gleiche Weise und wird in der zweiten Spezifikation festgelegt.

Grant Type	Beschreibung	Anwendungen
Authorization Code	Browserbasierter, flexibler Ablauf	Web, Apps
Implicit	vereinfachte Variante des Browser-Ablaufs für Clients, die direkt im Browser ausgeführt werden	JavaScript u.Ä.
Resource Owner Password Credentials	Benutzername und Passwort des Benutzers werden direkt in ein Access Token umgetauscht	Apps
Client Credentials	Nutzung von id und secret eines Clients für das Erlangen eines Access Token	Web
Refresh Token	Langlebiges Tokens, das zum Erlangen eines neuen Access Tokens verwendet wird	Web, Apps

Der vielseitigste Grant Type ist "Authorization Code", an dem sich der Ablauf des Protokolls illustrieren lässt. Beim Client handelt es sich um eine Webanwendung, die auf das Adressbuch des Benutzers zugreifen möchte. Der Client initiiert hierzu den OAuth-Browserflow, indem er eine HTTP-Weiterleitung zum Autorisierungs-Endpunkt des Authorization Server sendet:

https://accounts.service.com/oauth2/auth
     ?client_id=5365365163AF67BCD244534567
     &redirect_uri=https://photo-site.com/oauthcb
     &response_type=code
     &scope=contacts
      &state=4546454545

Diese Anfrage enthält einige interessante Informationen. Zum einen kann der Authorization Server den Client mit client_id identifizieren.

Der Parameter redirect_uri teilt ihm mit, zu welcher URL der Browser nach Abschluss des Autorisierungsprozesses weitergeleitet werden soll. Dabei handelt es sich in der Regel um eine spezielle (Callback-)URL für die Behandlung derartiger Vorgänge. response_type steuert den Protokollablauf, code selektiert den Grant Type „Authorization Code“. Im Parameter state übergibt der Client einen Wert an den Autorisierungsserver, den dieser dann unverändert nach dem Abschluss des Vorgangs an den Client zurücksendet. Damit kann der Client den Vorgang wiedererkennen und insbesondere CSRF-Angriffe (Cross-Site Request Forgery) erkennen und verhindern. Zu guter Letzt teilt der Client über den Parameter scope mit, für welche Ressourcen er welche Art von Zugriff anfordert. Der Wert von scope ist nicht durch den OAuth-Standard spezifiziert, ihn definieren derzeit jeder einzelne Autorisierungsserver sowie einzelne APIs selbst. Im Beispiel signalisiert der Client, dass er auf die Kontakte des Benutzers zugreifen möchte.

Im nächsten Schritt authentifiziert der Authorization Server den Benutzer. Da er hierbei in Interaktion mit dem Benutzer tritt, kann er hierfür jede gewünschte Methode einsetzen; eine Spezifikation dieses Schritts aus OAuth-Sicht ist nicht erforderlich. Dadurch ist der "Authorization Code" als flexibelster aller Grant Types anzusehen, denn die Schnittstelle zwischen Client und Authorization Server reduziert sich auf eine HTTP-Weiterleitung. Nach erfolgreicher Authentifizierung sollte der Authorization Server dem Benutzer den Authorization Request des Clients in geeigneter Weise anzeigen und um dessen Zustimmung bitten. In der Regel werden der Name und die URL des Clients zusammen mit den gewünschten Zugriffen angezeigt.

Vorsicht ist geboten, wenn sich die Daten hinsichtlich der Identität des Clients nicht prüfen lassen. Das ist bei sogenannten "Public Clients" der Fall. Sie besitzen nur eine client_id, aber kein korrespondierendes Geheimnis, das client_secret, und lassen sich daher nicht authentifizieren. In einem solchen Fall sind Angaben in Bezug auf den Client nicht durch den Authorization Server prüfbar. Dieser muss den Benutzer darauf hinweisen, die Entscheidung hinsichtlich der Authentizität des Clients muss dann der Benutzer treffen (siehe Abb. 4).

Gibt der Benutzer letztlich die Anfrage frei, sendet der Authorization Server eine Weiterleitung an die vom Client eingangs mitgeteilte redirect_uri, etwa: https://photo-site.com/oauthcb?code=4/5A-gmOdlpb4W-21LXQJKDTdhkDwU&state=4546454545. Als Parameter werden der Authorization Code und der State übertragen. Der Code repräsentiert die Autorisierung durch den Benutzer und wird im nächsten Schritt unmittelbar gegen ein Access Token getauscht. Dazu sendet der Client auf einer direkten HTTPS-Verbindung eine POST-Anfrage an den Authorization Server:

POST https://accounts.service.com/oauth2/tokens
    ?client_id=5365365163AF67BCD244534567
    &client_secret=E6x...FVu3
    &grant_type=authorization_code
    &redirect_uri=https%3A%2F%2Fphoto-site.com%2Foauthcb
    &code=4/5A-gmOdlpb4W-21LXQJKDTdhkDwU

In der Anfrage ist dieselbe client_id wie beim initialen Authorization Request zu verwenden, in dem Fall ergänzt um das korrespondierende client_secret. Erst danach lässt sich hiermit der Client authentifizieren. Das client_secret wird erst in diesem Schritt übertragen, weil es hier im Gegensatz zum Redirect gegen Ausspähen gesichert ist. Mit dem Parameter grant_type selektiert der Client in diesem Fall den Grant Type Authorization Code. Als Konsequenz erwartet der Authorization Server zwei weitere Parameter, nämlich die initial verwendete redirect_uri und den Code. Nach erfolgreicher Prüfung aller Parameter sendet der Server folgendes JSON-Objekt in der HTTP-Response:

{
 "access_token":
 "ya29.AHE...5CLRaw",
 "token_type": "Bearer",
 "expires_in": 3600,
 "refresh_token": "1/wMTx...mmyI"
 }

Neben dem Access Token enthält das Objekt Informationen zum Typ des Access Token und dessen Laufzeit (in Sekunden). Des Weiteren stellt der Authorization Server in diesem Fall zusätzlich ein Refresh Token aus. Nun kann der Client das erste Mal auf das Adressbuch des Benutzers zugreifen. Hierzu verwendet er den Access Token und sendet diesen im Authorization Header mit jeder Anfrage mit. Der Authorization Header nutzt das oben erwähnte neue HTTP-Autorisierungsschema Bearer:

GET https://mail.service.com/contacts/people/@me/@all

Authorization: BEARER ya29.AHE...5CLRaw

{
    "startIndex": 0,
    "totalResults": 3,
    "entry": [
        {
            "profileUrl":
"https://mail.service.com/contacts/profiles/user1ID", ...

Und was ist mit Apps?

Der Grant Type „Authorization Code“ lässt sich verwenden, um Access Tokens für mobile und Desktop-Anwendungen zu erlangen. Da diese Anwendungen in der Regel nicht in einem Browser ausgeführt werden, muss man hier einen "Umweg" in Kauf nehmen. Im Wesentlichen gibt es zwei Muster für die Integration dieser Anwendungen mit OAuth. Die Anwendung kann die Ausführung des OAuth-Flows an den auf dem Gerät installierten Browser übergeben. Das hat den Vorteil, dass sich Sitzungen mit dem Dienstanbieter wiederverwenden lassen.

Der Rücksprung in die Anwendung gestaltet sich aber etwas schwieriger. Hierzu wird ein sogenanntes "Custom URL Scheme" für die redirect_uri verwendet. Es kommt anstelle eines Standardschemas wie https ein speziell für die Anwendung definiertes Schema wie myapp zum Einsatz. redirect_uri könnte dann wie folgt aussehen: myapp://redirect/oauthcb. Im Browserkontext muss das Schema mit der Anwendung als Handler assoziiert sein. Dann aktiviert der Browser beim Rücksprung aus dem Autorisierungsprozess die Anwendung und übergibt ihr die Rücksprungs-URL, zum Beispiel:

myapp://redirect/oauthcb?code=4/5A-gmOdlpb4W-21LXQJKDTdhkDwU&state=4546454545

Diese Technik ist weitverbreitet, aber mit folgenden Herausforderungen behaftet: Die Aktivierung eines Handlers wird von vielen modernen Browsern wie jeder andere Aufruf eines ausführbaren Programms behandelt und erfordert die Zustimmung des Benutzers. Da die Ausführung von Programmen im Kontext von Webseiten im Allgemeinen mit Schadsoftware assoziiert wird, werden viele Benutzer wahrscheinlich an der Stelle den Prozess abbrechen. Des Weiteren könnte eine Schadsoftware auf dem Gerät einen eigenen Handler für das Custom Scheme registrieren, den Rückruf abfangen und selbst das Token abfragen und verwenden. Zu guter Letzt unterstützen nicht alle Plattformen Custom Schemes.

Die Alternative stellt die Einbettung eines Browsers in die Anwendung dar. Bei der Technik führt die Anwendung den Autorisierungsprozess im eingebetteten Browser durch und beobachtet den Nachrichtenfluss. Als Ziel der redirect_uri wird in dem Fall eine lokale oder Serverressource verwendet. Die Anwendung extrahiert dann den Authorization Code direkt aus der URL.

Die beschriebenen Muster sind eindeutig aufwendiger zu implementieren als die Integration einer Webanwendung. Warum sollte man diesen Aufwand treiben und sendet nicht einfach Benutzername sowie Passwort an den Autorisierungsserver? Das kann man auch tun. Hierzu gibt es den Grant Type "Resource Owner Password Credentials". Aber wieder ist das Passwort-Anti-Pattern zu beachten.

Wenn App und Resource Server zum selben Dienstanbieter gehören und eine sorgsame Behandlung der Passwörter sichergestellt ist, ist dagegen nichts einzuwenden.

Handelt es sich aber um die Anwendung einer dritten Partei, ist das kritisch zu sehen. Hinzu kommt, dass bei der direkten Verwendung von Benutzernamen und Passwort die direkte Interaktion zwischen Benutzer und Authorization Server entfällt. Der Authorization Server kann also die Freigabe des Zugriffs nicht direkt beim Benutzer nachfragen. Damit tritt das Prinzip der Benutzerkontrolle in den Hintergrund. Deshalb bieten viele Internet-Dienstanbieter den Grant Type "Resource Owner Password Credentials" gar nicht erst an.

Fazit

Aus Sicht der Autoren bringt OAuth 2.0 in diversen Aspekten eine Verbesserung mit sich. Die bei der Deutschen Telekom gesammelten Erfahrungen zeigen, dass OAuth 2.0 durch eine gute Balance zwischen Einfachheit, Skalierbarkeit und Sicherheit gekennzeichnet ist.

Die Integration ist im Vergleich zu OAuth 1.0a deutlich einfacher geworden. Gerade die Verwendung digitaler Signaturen auf Protokollebene hat den Integrationspartnern immer wieder Probleme bereitet. Digitale Signaturen bieten aber nur in Einzelfällen einen Sicherheitsgewinn, wenn man das Protokoll über Ende zu Ende terminiertes TLS (Transport Layer Security) betreibt.

Um sicherzustellen, dass trotz des Verzichts auf digitale Signaturen das OAuth-2.0-Protokoll ein angemessenes Sicherheitsniveau erreicht, hat die OAuth-Arbeitsgruppe bei der IETF eine umfangreiche Gefahrenanalyse durchgeführt und dokumentiert. Des Weiteren durchlief das Protokoll Reviews in der Arbeitsgruppe, bei den Sicherheitsteams der beteiligten Unternehmen und im Rahmen des IETF-weiten Freigabeprozesses. Die Ergebnisse flossen in das Protokolldesign beziehungsweise in die Security Considerations der Spezifikationen ein und sind von allen Implementierungen zu beachten.

Aus architektonischer Sicht hat die Trennung zwischen Token-Ausstellung und -Verwendung erhebliches Potenzial. Es wird hiermit möglich, dieselbe Schnittstelle (oder API) für Zugriffe von unterschiedlichsten Geräten aus und in verschiedenen Geschäftsmodellen zu verwenden. Die Spezifikationen für den Kern von OAuth 2.0 wurden im Oktober 2012 als RFCs (Request for Comments) veröffentlicht. Frühere Draft-Versionen werden seit längerer Zeit eingesetzt. Das hat zum einen zur Reife des Protokolls beigetragen. Zum anderen ist das Protokoll im Kern seit 2011 stabil, danach wurden nur noch kleine Änderungen vorgenommen und die Beschreibung des Protokolls präzisiert sowie die Sicherheitsüberlegungen ergänzt.

OAuth ist im Markt angekommen, jetzt muss man Erfahrungen sammeln und es sukzessive weiterentwickeln. Das langfristige Ziel der IETF ist es, dass OAuth das Standard-Autorisierungsprotokoll für HTTP-Protokolle wird und damit die Basic Authentifizierung zumindest ergänzt, wenn nicht gar ersetzt. Eine Verwendung zur Absicherung anderer Protokolle wie IMAPist ebenfalls in Arbeit. Kurzfristig wird der Schwerpunkt auf der Verbesserung der Interoperabilität zwischen unterschiedlichen Implementierungen liegen. Dazu wird an weiteren, ergänzenden RFCs, zum Beispiel für die dynamische Registrierung von Clients und das Format JSON Web Token (JWT) gearbeitet.

Daneben besteht großer Bedarf für die Entwicklung eines tragfähigen Ansatzes im Bereich des Identity Providing. Denn obwohl OAuth heute beim Login auf Webseiten zum Einsatz kommt, ist zu konstatieren, dass es hierfür nicht gedacht und daher auch ungeeignet ist. Stattdessen arbeitet eine Arbeitsgruppe bei der OpenID Foundation an einem OAuth-basierten Nachfolger von OpenID 2.0, genannt OpenID Connect. Entwickler werden davon profitieren, dass sich in der Kombination von OAuth und OpenID Connect sowohl das Login als auch der Zugriff auf geschützte Ressourcen mit demselben Basisprotokoll, OAuth, durchführen lassen.

Dr. Torsten Lodderstedt
ist Product Owner für Identitäts-Management bei der Deutschen Telekom und verantwortet die Entwicklung von Enablern für das Login in diverse Endkundenprodukte. Er ist an der Spezifikation von OpenID Connect und OAuth beteiligt. Seine Schwerpunkte sind hierbei Architektur, mobile Apps und Sicherheit.

Jochen Hiller
arbeitet als Developer Evangelist bei der Deutschen Telekom. Er hat als Systemarchitekt die IDM-Plattform für Privatkunden verantwortet. Derzeit ist er Product Owner für das SDK einer Plattform für das intelligente Haus.

Literatur

• Paul Sevinç; Auftragsarbeit; OAuth – sichere Benutzung von Web-APIs; iX 7/2009, S. 118
• Lofi Dewanto; Herr Müller, sind Sie's? Autorisierungsdienste mit OAuth; Artikel auf heise Developer

(ane)