OAuth2: Difference between revisions
No edit summary |
No edit summary |
||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
Hier eine Zusammenfassung meines Vortrages und meine persönliche Meinung zum Thema OAuth 2.0. |
|||
=== Was ist OAuth === |
=== Was ist OAuth === |
||
„OAuth ist ein offenes Protokoll, das eine standardisierte, sichere API-Autorisierung für Desktop-, Web- und Mobile-Applikationen erlaubt.“ |
„OAuth ist ein offenes Protokoll, das eine standardisierte, sichere API-Autorisierung für Desktop-, Web- und Mobile-Applikationen erlaubt.“ |
||
Line 23: | Line 25: | ||
Bevor OAuth verwendet werden kann, muss sich der Client vom Resource Server als ein möglicher OAuth-Client autorisieren lassen. Wie dies geschieht ist nicht in OAuth beschrieben. |
Bevor OAuth verwendet werden kann, muss sich der Client vom Resource Server als ein möglicher OAuth-Client autorisieren lassen. Wie dies geschieht ist nicht in OAuth beschrieben. |
||
Nachfolgend der abstrakte Protokollfluss<ref>http://tools.ietf.org/html/rfc6749#section-1.2</ref>. |
|||
<pre> |
<pre> |
||
+--------+ +---------------+ |
+--------+ +---------------+ |
||
Line 57: | Line 59: | ||
=== Wo man es findet === |
=== Wo man es findet === |
||
OAuth in der Version 2 wird verwendet von zu min. folgenden Seiten |
OAuth in der Version 2 wird verwendet von zu min. folgenden Seiten<ref>http://en.wikipedia.org/wiki/OAuth#List_of_OAuth_Service_Providers</ref> |
||
*HnyB.me |
*HnyB.me |
||
Line 82: | Line 84: | ||
=== Sicherheit === |
=== Sicherheit === |
||
Im allgemeinen wird OAuth 2 als sich betrachtet. Dem ist grundlegend nicht zu widersprechen, nur wurde OAuth 2 als Framework entworfen und ist als solches kein eigenständiges System. Bei einer abschließenden Bewertung der Sicherheit sollte allerdings immer ein Gesamtsystem bewertet werden, um keine Missverständnisse aufzuwerfen. |
|||
OAuth 2 als Framework bietet per Design die Möglichkeit es zu erweitern, um es in ein Sicherheitsmodell von Kontoanbietern möglichst leicht zu integrieren. Und genau hier beginnt die Frage nach der Sicherheit von OAuth 2 zu einer juristischen Frage zu mutieren. Aus technischer Sicht, ist die Sicherheit des OAuth 2 Frameworks im Grunde losgelöst von der Unsicherheit seiner Erweiterungen. Aus der Endanwendersicht könnte dies etwas anders aussehen. |
|||
Eine Analogie wäre ein Hochsicherheitsschloss an einer Plastikkette. Hier ist augenscheinlich klar, dass solch ein System trotz des sicheren Schlosses unsicher ist. |
|||
In der Digitalen Welt ist die Sicherheit eines Systems leider ganz und gar nicht so augenscheinlich. Interessierten Anwendern würde vermutlich der Zugang zu Informationen zur genauen OAuth 2 Implementierung / Anbindung des Kontoanbieters verwehrt bleiben. Und die überragende Mehrheit der Kontoinhaber würde das OAuth-Logo vermutlich gar nicht hinterfragen. |
|||
== Einzelnachweise == |
== Einzelnachweise == |
||
Line 92: | Line 101: | ||
* [http://tools.ietf.org/html/draft-ietf-oauth-v2-31 IETF] |
* [http://tools.ietf.org/html/draft-ietf-oauth-v2-31 IETF] |
||
* [http://en.wikipedia.org/wiki/OAuth Wiki about OAuth] |
* [http://en.wikipedia.org/wiki/OAuth Wiki about OAuth] |
||
* [http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/ Kritik an OAuth 2] |
Latest revision as of 23:05, 19 December 2012
Hier eine Zusammenfassung meines Vortrages und meine persönliche Meinung zum Thema OAuth 2.0.
Was ist OAuth
„OAuth ist ein offenes Protokoll, das eine standardisierte, sichere API-Autorisierung für Desktop-, Web- und Mobile-Applikationen erlaubt.“ <ref>http://de.wikipedia.org/wiki/OAuth</ref>
OAuth wird verwendet, um jemanden einen Zugriff auf ein Konto zu geben, ohne die Zugangsdaten des Kontoinhabers weiterzugeben. Dieser Zugriff kann auf spezielle Daten eingegrenzt sein und ist zeitlich limitiert. Weiter kann der Zugriff jeder Zeit vom Kontoinhaber widerrufen werden.
Wie Funktioniert es
Begriffe
Bezeichnung | Bedeutung |
---|---|
Client | Anwendung, welche auf die Kontodaten zugreifen möchte |
Resource Owner | Kontoinhaber |
Authorization Server | Autorisierungsdienst des Kontoanbieters |
Resource Server | Kontoanbieter |
Autorisierung
Bevor OAuth verwendet werden kann, muss sich der Client vom Resource Server als ein möglicher OAuth-Client autorisieren lassen. Wie dies geschieht ist nicht in OAuth beschrieben.
Nachfolgend der abstrakte Protokollfluss<ref>http://tools.ietf.org/html/rfc6749#section-1.2</ref>.
+--------+ +---------------+ | |--(A)- Authorization Request ->| Resource | | | | Owner | | |<-(B)-- Authorization Grant ---| | | | +---------------+ | | | | +---------------+ | |--(C)-- Authorization Grant -->| Authorization | | Client | | Server | | |<-(D)----- Access Token -------| | | | +---------------+ | | | | +---------------+ | |--(E)----- Access Token ------>| Resource | | | | Server | | |<-(F)--- Protected Resource ---| | +--------+ +---------------+
- A: Will nun der Client auf ein Konto zugreifen wendet er sich zunächst an den Resource Owner. Der Client erbitte eine Genehmigung, um auf das Konto des Resource Owner(s) zugreifen zu können.
- B: Der Client erhält die Genehmigung.
- C: Der Client erbittet einen Access Token.
- D: Wenn die Genehmigung vom Resource Owner vom Authorization Server akzeptiert wird, sendet dieser den Access Token an den Client zurück.
- E: Der Client beantragt mit dem Access Token die gewünschten Daten vom Resoure Server.
- F: Sollte der Access Token akzeptiert werden, sendet der Resource Server die angefragten Daten zurück.
Wo man es findet
OAuth in der Version 2 wird verwendet von zu min. folgenden Seiten<ref>http://en.wikipedia.org/wiki/OAuth#List_of_OAuth_Service_Providers</ref>
- HnyB.me
- bitly
- Formstack
- Foursquare
- GitHub
- vInstagram
- Hotmail
- Windows Live
- Messenger
- Xbox
- PayPal
- Sina Weibo
- Stripe.com
- Tent.io
- VK
- Veevop
- Yammer
- Yandex
Sicherheit
Im allgemeinen wird OAuth 2 als sich betrachtet. Dem ist grundlegend nicht zu widersprechen, nur wurde OAuth 2 als Framework entworfen und ist als solches kein eigenständiges System. Bei einer abschließenden Bewertung der Sicherheit sollte allerdings immer ein Gesamtsystem bewertet werden, um keine Missverständnisse aufzuwerfen.
OAuth 2 als Framework bietet per Design die Möglichkeit es zu erweitern, um es in ein Sicherheitsmodell von Kontoanbietern möglichst leicht zu integrieren. Und genau hier beginnt die Frage nach der Sicherheit von OAuth 2 zu einer juristischen Frage zu mutieren. Aus technischer Sicht, ist die Sicherheit des OAuth 2 Frameworks im Grunde losgelöst von der Unsicherheit seiner Erweiterungen. Aus der Endanwendersicht könnte dies etwas anders aussehen.
Eine Analogie wäre ein Hochsicherheitsschloss an einer Plastikkette. Hier ist augenscheinlich klar, dass solch ein System trotz des sicheren Schlosses unsicher ist.
In der Digitalen Welt ist die Sicherheit eines Systems leider ganz und gar nicht so augenscheinlich. Interessierten Anwendern würde vermutlich der Zugang zu Informationen zur genauen OAuth 2 Implementierung / Anbindung des Kontoanbieters verwehrt bleiben. Und die überragende Mehrheit der Kontoinhaber würde das OAuth-Logo vermutlich gar nicht hinterfragen.
Einzelnachweise
<references />