Authentication im Web

Gründe für Authentifizierung

Ob Social-Network, Wettportal oder Online-Fotodienst. Nahezu jeder Dienst im WWW benötigt eine Speicherung von nutzerspezifischen Daten. Dies ist der Grund warum eine sichere Authentifizierung im Web unerlässlich ist. Einige Dienste, wie zum Beispiel die oben genannten Wettportale speichern sensible Nutzerdaten wie Kontonummer und Bankleitzahl. Authentifizierung dient vor allem dem Schutz dieser Daten mit Hilfe von verschiedenen Authentifizierungs-Mechanismen.

Authentifizierungsmöglichkeiten

Passwort

Im WWW hat sich die Authentifizierung mit Hilfe von Nutzername und Passwort durchgesetzt. Der Nachteil an diesem Verfahren ist zur Zeit offensichtlich. Die Sicherheit hängt bei dieser Authentifizierungsmöglichkeit von der Sicherheit des Passworts ab. Das bedeutet also, um optimale Sicherheit zu garantieren, benötigt man für jede Website ein neues Passwort, das idealerweise aus Sonderzeichen, Zahlen, Klein- und Großbuchstaben besteht und eine angemessene Länge hat. Natürlich ist dies nicht unbedingt nutzerfreundlich, da es den meisten Menschen schwer fallen dürfte, bei mehr als 10 Diensten sich an alle Passwörter zu erinnern. Die Folge: Nutzer beschränken sich häufig auf ein Passwort, das sie für jeden Dienst nutzen. Wenn ein Hacker also das Passwort eines Dienstes knacken konnte, stehen ihm alle Konten des Nutzers zur Verfügung. Die andere Möglichkeit: Der Nutzer verwendet nur noch kurze Passwörter, an die er sich leicht erinnern kann. Was wiederum die Chancen eines Hackers auf Erfolg des Knackens eines Passworts deutlich erhöht.
Dass dieses Thema scheinbar immernoch nicht in das Bewusstsein aller Nutzer vorgedrungen ist, kann man an folgendem Beispiel sehr gut erkennen. Das Portal Rockyou speicherte die Passwörter aller Nutzer im Klartext ab, als im Januar 2010 ein Hacker auf Grund eines Bugs in der Datenbank an alle 32 Millionen Passwörter kam. Daraufhin analysierte das Marktforschungsinstitut imperva die Passwörter und veröffentlichte eine Liste mit den beliebtesten.

Rank	Password	absolute Number of Users with Password
1	123456	290.731
2	12345	79.078
3	123456789	76.790
4	Password	61.958
5	iloveyou	51.622
6	princess	35.231
7	rockyou	22.588
8	1234567	21.726
9	12345678	20.553
10	abc123	17.542
11	Nicole	17.168
12	Daniel	16.409
13	babygirl	16.094
14	monkey	15.294
15	Jessica	15.162
16	Lovely	14.950
17	michael	14.898
18	Ashley	14.329
19	654321	13.984
20	Qwerty	13.856

Am Bild wird offensichtlich, dass viele Nutzer noch auf viel zu leichte Passwörter zurückgreifen und damit ihre Nutzerdaten fast frei zugänglich machen. "123456" liegt auf Platz 1, da das Portal eine Mindestlänge von 6 Buchstaben voraussetzte. "12345" muss demnach ein älteres Passwort sein, das Nutzer gewählt haben, bevor diese Umstellung kam.

Zertifikat

Authentifizierung ist auch mit Hilfe eines Zertifikats möglich. Dies gilt zunächst als Sicherer, weil die Rolle vom Passwort vom Zertifikat übernommen wird, das heißt der Nutzer muss sich kein Passwort mehr merken. Der dem Passwort entsprechende Teil wird innerhalb des Zertifikates generiert und kann dementsprechend aus mehr Zeichen bestehen, als ein Passwort, das sich ein Mensch merken muss. Allerdings haben die Betreiber der Website größeren Aufwand, da sie die Zertifikate verwalten müssen. Auf Grund dieses Nachteils hat sich die Technik im WWW nicht durchgesetzt. Im Folgenden wird deshalb auch nicht weiter auf dieses Thema eingegangen.

Authentifizierung vs. Autorisierung

Authentifizierung und Autorisierung werden oft miteinander verwechselt, daher folgt hier eine kleine Abgrenzung der beiden Begriffe

Authentifizierung

Bei der Authentifizierung geht es darum seine Identität mit Hilfe von verschiedenen Mitteln zu beweisen. Beispielsweise Personalausweis, Fingerabdruck, Passwort. Der Satz "Ich bin Max Mustermann und ich kann es beweisen" demonstriert ganz gut die Intention der Authentifizierung.

Autorisierung

Beim Thema Autorisierung verwaltet man vor allem Rechte. Man legt also für verschiedene Nutzer verschiedene Rechte fest. Allerdings offenbart sich an dieser Stelle schon, dass Autorisierung ohne Authentifizierung nicht möglich ist. Um einem bestimmten Nutzer Rechte zu verleihen, ist es schließlich dringend notwendig seine Identität zu wissen, beziehungsweise diese bestätigt zu wissen. Der Satz "Ich erlaube Max Mustermann an meine Pinnwand zu posten" demonstriert hier anhand eines Beispiels die Intention der Autorisierung.

HTTP Basic Authentication

Die einfachste Form der Authentifizierung im WWW ist die HTTP Basic Authentication. Da sie, wie der Name schon vermuten lässt, Bestandteil des HTTP-Protokolls ist, wird diese Form der Authentifizierung von allen Browsern unterstützt. Der Nachteil hierbei ist allerdings, dass der Nutzername und das Passwort im Klartext zum Server übertragen werden. Wenn ein Angreifer also die Möglichkeit hat, die Leitung abzuhören, weil er beispielsweise im gleichen Netzwerk ist, erhält er unverzüglich die Login-Daten des Nutzers. Es gibt inzwischen allerdings schon eine Digest-Authentifizierung. Hierbei sendet der Server im WWW-Authenticate-Header eine zufällig generierte Zahlenfolge, woraufhin der Browser aus Zahlenfolge, Passwort und Nutzername einen Hashcode berechnet, den er wieder zum Server schickt. Dieser muss nun nur noch die Prüfsumme berechnen und vergleichen. Der Vorteil bei diesem Verfahren ist natürlich, dass ein Angreifer aus dem Abhören der Leitung nicht unmittelbar auf Nutzername und Passwort schließen kann. Kennt er allerdings die Hashfunktion, kann er theoretisch per Brute-Force versuchen, Nutzername und Passwort zu erraten, und kann mit Hilfe des zufälligen Zahlen-Codes und des abgehörten Hashwertes vergleichen, ob sein geratener Nutzername und sein geratenes Passwort im Hashwert dem Originalen Hashwert entsprechen. Ob dieses Verfahren Aussicht auf Erfolg hat, hängt vor allem vom gewählten Nutzernamen und dem gewählten Passwort ab.

Basic Authentication Tutorial

Aber nun zur Einrichtung von Basic Authentication unter einem Apache Server. In diesem Beispiel soll folgendes erreicht werden: Der Bereich "Test" unseres Servers soll nur für den Benutzer Fred zugänglich sein. Zuerst einmal benötigt man ein User-File. In diesem müssen sich später alle User mit Nutzername und Passwort registrieren. In den Einstellungen des Servers wird später festgelegt, welches User-File er verwenden soll, um Usern Zugriff zu gewähren oder nicht. Das User-File erstellt man mit Hilfe des Kommandozeilen-Tools htpasswd. Zu beachten ist noch, dass man für sämtliche Aufrufe des Tools htpasswd Administrationsrechte benötigt, weswegen es nötig ist, vor die meisten Aufrufe ein sudo zu schreiben. Mit dem Aufruf

htpasswd -c /Users/TestUser/desktop/passwd Fred

erstellt man sich zunächst einmal ein User-File (welches sich dann auf dem Desktop des TestUsers befindet). Zusätzlich wird schon der erste Benutzer angegeben (Fred). Das Programm fragt nun nach dem Passwort vom Benutzer Fred und bittet darum, dies auch zu bestätigen. Hier wählt Fred das Passwort "test". Schaut man danach in der erstellten Datei nach, wird man folgendes sehen.

Fred:$apr1$OgVOEBG6$ZCRAVPLO3mVpm2KG.luG3.

Wie man sieht, wurde das Passwort von Fred bereits gehasht.

Neue Nutzer lassen sich einfach wie folgt hinzufügen.

htpasswd /User/TestUser/desktop/passwd "newUser"

Damit wäre die Grundvoraussetzung für das Beispiel gegeben. Als nächstes ist die Datei "httpd.conf" zu bearbeiten. Sie befindet sich meist in einem config Unterordner des Apache Servers. In der Datei sucht man nun nach dem ersten Directory-Tag. Aus dem AllowOverride None macht man ein AllowOverride AuthConfig, sodass am Ende folgendes dastehen müsste:

 <Directory />
    Options Indexes FollowSymLinks
    AllowOverride AuthConfig
</Directory>

Für den nächsten Schritt gibt es 2 Möglichkeiten: Man kann entweder alle Angaben zur Berechtigung in .htaccess-Files auslagern, oder aber die Angaben direkt in die httpd.conf Datei schreiben. An dieser Stelle wird zunächst der zweite Schritt demonstriert.
Es ist nun möglich in der httpd.conf-Datei unter den letzten Directory-Tag weitere hinzuzufügen. Dieser sieht im Beispiel wie folgt aus:

 <Directory "/Users/TestUser/Sites/Test">
	AuthType Basic
	AuthName "Für diesen Bereich ist eine Authentifizierung erforderlich"
	AuthUserFile /Users/TestUser/desktop/passwd
	Require user Fred
</Directory>

Im Directory Tag muss der Ordner angegeben werden, den man schützen möchte. In unserem Fall liegt das Root-Verzeichnis des Servers unter /Users/TestUser/Sites. Daher wird der Ordner /Users/TestUser/Sites/Test geschützt. Bei AuthType lässt sich zwischen Digest und Basic wählen. Bei Digest werden Nutzername und Passwort vor der Übertragung gehasht. AuthName beschreibt den Text, den ein Nutzer bei Aufruf der Seite zu sehen bekommen soll. Unter AuthUserFile muss nun das zuständige User-File übergeben werden, das am Anfang erstellt wurde. Mit Require user kann man nun den Nutzer angeben, der auf den Ordner Zugriff haben soll.
Zusätzlich ist es auch möglich Groupfiles anzulegen, in denen man eine Gruppe angibt und festglegt, welche Nutzer der Gruppe angehören. Im Vergleich zum obigen Directory-Tag kommt lediglich der Abschnitt

 AuthGroupFile /Users/TestUser/desktop/groupfile

hinzu. Dieser enthält den Pfad zum erstellten GroupFile. Aus dem Require user kann dann ein Require group gemacht werden und eine Gruppe von Nutzern angegeben werden, die dann die Berechtigung erhält, auf den Bereich zuzugreifen. Die Syntax von Groupfiles ist sehr simpel gehalten.

 AF: Alex Fred

Solch ein Eintrag in einem Groupfile bedeutet, dass die Nutzer Alex und Fred der Gruppe AF angehören.

Single-Sign-On

Um die verschiedenen Probleme, die mit dem ursprünglichen Verfahren (für jeden Dienst wird ein Nutzername und ein Passwort benötigt) zu lösen, entstand die Idee des Single-Sign-On. Hierbei meldet sich ein Nutzer einmal an, beispielsweise bei einem OpenID-Provider, Facebook etc. und kann sich bei anderen Diensten mit Hilfe seinen Facebook Accounts oder seiner URL von OpenID anmelden. Die Vorteile hierbei sind vielfältig, so muss ein Nutzer sich beispielsweise im Idealfall nur noch ein Passwort merken und kann dadurch ein langes sicheres Passwort wählen. Die Anbieter der "Sekundärdienste" müssen sich zudem nicht um die Verwaltung der Passwörter kümmern. Dadurch wird Zeit und Geld gespart, da viele Sicherheitsvorkehrungen, die sonst nötig gewesen wären, wegfallen. Der Nachteil bei allen Anbietern ist aber auch, das im schlimmsten Fall ein Angreifer mit dem Knacken des einen Passworts auf alle anderen Dienste des Nutzers zugreifen kann. Bekannte Single-Sign-On Anbieter sind die Social-Networks (Facebook, Twitter, Google, Windows Live, Yahoo). Um als Entwickler das Login all dieser Plattformen zu unterstützen, ist es hilfreich auf eine schon vorhandene Bibliothek zuzugreifen, beispielsweise von Janrain. Andere Anbieter sind OpenID und auch OAuth kann man dazuzählen, obwohl der Fokus bei dieser Technik deutlich mehr auf der Autorisierung, als auf der Authentifizierung liegt.

OpenID

Grundsätzlich benötigt man bei OpenID 3 Komponenten: Den User, den OpenID Konsument und den OpenID Provider. Der User möchte auf die Dienste eines OpenID Konsumenten zugreifen. Um sich bei diesem Dienst anzumelden, verwendet er die URL, die er vom OpenID Provider erhalten hat. Sollte er dort noch nicht eingeloggt sein, wird er vom Konsumenten auf die Seite des Providers weitergeleitet um dort sein Passwort einzugeben. Man hat bei diesem Verfahren also alle oben genannten Vor- und Nachteile des Single-Sign-On Verfahrens. Ein zusätzlicher Vorteil bei OpenID ist die breite Unterstützung, die OpenID mittlerweile hat. Im Januar 2008 soll es schon 368 Millionen registrierte Konten gegeben haben. Zu den Unterstützern zählen Facebook, Google, IBM, Microsoft, Paypal, Myspace, oder Yahoo. Das Verfahren hat allerdings auch einige Nachteile:

• Es ist volles Vertrauen in den OpenID Provider nötig. Dieser erhält nämlich eine Fülle von Daten des Users. Er sieht jeden Dienst, den der Nutzer verwendet hat, hat vielleicht sensibele Daten wie Bank- und Adressdaten und kann möglicherweise sogar Bewegungsprofile erstellen.
• Das Verfahren ist oft nicht vollständig implementiert. So lassen viele Konsumenten nur das Login von bestimmten OpenID-Providern zu, die meist auch der gleichen Firma wie die Konsumenten angehören. Dies ist der Fall, da viele Firmen Interesse daran haben, der eine OpenID Provider des Nutzers zu werden und hoffen in Zukunft in den Genuss, der Nutzerdaten zu kommen.
• Die Phishing-Gefahr ist relativ hoch. So wäre es beispielsweise leicht für einen Konsumenten, den Nutzer gar nicht auf die Seite des wirklichen OpenID Providers weiterzuleiten, sondern auf eine selbst angelegte Seite, die einzig und allein dem Zweck dient, die Login-Daten des Nutzers zu bekommen. Dies hätte natürlich wieder den Nachteil, dass der Angreifer somit Zugriff auf sämtliche Dienste des Nutzers hätte. Die Gefahr lässt sich allerdings mit Hilfe von SSL einschränken.
• Open ID bietet keine Verschlüsselungs- oder Sicherheitsstandards. Das heißt also, man kann OpenID Provider werden, ohne sicherzustellen, dass man die Nutzerdaten vor Zugriffen von außen schützt. Es gibt zwar eine OpenID Provider Blacklist, auf der Provider stehen, die in der Vergangenheit schlecht mit Nutzerdaten umgegangen sind, aber bis man auf dieser steht, können einige Nutzer schon getäuscht worden sein.

OAuth

OAuth ist ein Protokoll, das hauptsächlich Autorisierungsfragen spezifiziert. So ist es beispielsweise mit Hilfe von OAuth möglich, APIs sicher zugänglich zu machen. Aber auch das allgemeine Zugreifen eines Dienstes auf Daten eines anderen Dienstes wird durch OAuth geregelt. Auch bei OAuth werden 3 Komponenten benötigt: Der User, der OAuth Consumer und der OAuth Service Provider.

Geschichte

OAuth 1.0 wurde am 3. Oktober 2007 veröffentlicht. Bei Twitter beispielsweise ist es seit 31. August 2010 für alle Applikationen von Drittanbietern in Benutzung, wenn auch in der Version 1.0a. Seit kurzem ist die Version 2.0 veröffentlicht, die einige Änderungen am Protokoll enthält. Es ist zudem nicht abwärtskompatibel. In Verwendung ist OAuth 2.0 bereits bei Facebook, Google, Microsoft oder Github. Andere Anbieter wie Twitter, Yahoo, Flickr oder Myspace setzen immernoch auf OAuth 1.0a.

Beispiel

Hier nun einmal die Verwendung von OAuth an einem Beispiel. Anna möchte gern beim fiktiven Dienst Beppa Fotos ausdrucken lassen, die sie sich dann schicken lässt. Sie möchte Beppa allerdings nicht direkt die Fotos senden, sondern vielmehr Beppa Zugriff auf die Fotos ihres sozialen Netzwerkes Facebook geben. In diesem Beispiel wäre Anna also der User, Beppa der OAuth Consumer und Facebook der OAuth Service Provider. Die Kommunikation zwischen Consumer und Service Provider lässt sich an folgendem Bild gut zeigen.

Zunächst sagt Anna dem Dienst Beppa, dass ihre Fotos bei Facebook liegen. Beppa muss sich vorher bereits bei Facebook als OAuth Consumer registriert haben. Bei der Registrierung hat Beppa von Facebook einen sogenannten Consumer Key und ein Consumer Secret bekommen. Das Consumer Secret muss stets geheim gehalten werden. Mit diesen Daten können sich Konsumenten gegenüber dem OAuth Service Provider verifizieren. Dies geschieht im ersten Schritt: Um ein Request Token zu erhalten müssen Consumer Key und Secret zueinander passen und bei Facebook registriert sein. Mit Erhalt des Request Tokens und Request Token Secrets, kann Beppa den Nutzer nun auf die spezielle Website von Facebook leiten, auf der Anna im Anschluss alle Schritte zur Autorisierung vornehmen kann. Der OAuth Standard unterstützt hierbei die völlige Flexibilität der Autorisierung. Bei Facebook und Twitter bekommt man als Nutzer zwar ein Paket vorgesetzt, in dem beschrieben ist, welche Rechte die App hat, woraufhin man dieses Paket als ganzes nur noch akzeptieren oder ablehnen kann. Theoretisch sieht der Standard aber auch vor, dass der User entscheiden kann, mit welchen Rechten er die App des Consumers ausstattet oder nicht, aber zurück zum Beispiel. Anna hat nun Beppa den Zugriff auf ihre Fotos gewährt und wird nun zurück zu Beppa geleitet. Beppa kann nun mit Hilfe des bereits erhaltenen Request Tokens und Request Token Secrets ein Access Token von Facebook für Anna anfordern. Facebook überprüft nun, ob Anna Beppa auch autorisiert hat und gewährt das Access Token wenn dies der Fall ist. Mit Hilfe des Access Tokens kann Beppa nun die Facebook-API ansprechen und so Zugriff auf Anna's Fotos erlangen und diese ausdrucken.

Tutorial

Im folgenden soll die Verwendung von OAuth an einem Beispiel demonstriert werden. Auf einer selbst erstellten Website soll mit Hilfe von OAuth auf die Twitter API zugegriffen werden, sodass man anzeigen kann, wem der angemeldete User folgt oder etwas im Namen des Users twittern kann. Hierzu stellt oauth.net Libraries aus diversen Programmiersprachen zur Verfügung. Unter anderem werden Ruby,Python und PHP unterstützt. In diesem Tutorial soll aber auf ein Github Repository vom User joechung zurückgegriffen werden, welcher speziell zum Ansprechen der Twitter-API eine Library in PHP geschrieben hat. Bevor man beginnen kann, ist es notwendig auf Twitter eine App zu erstellen und diese mit einem "Rechte-Paket" auszustatten. Hat man sich erfolgreich als Entwickler registriert, erhält man von Twitter einen Consumer Key und ein Consumer Secret. Nun kann auf das Repository zurückgegriffen werden. Es enthält insgesamt 5 Dateien. Die getreqtok.php kümmert sich um das Erhalten des Request Tokens, sowie die getacctok.php für den Erhalt des Access Tokens zuständig ist. In globals.php muss der Twitter Consumer Key und das Consumer Secret angegeben werden. In OAuthHelper sind einige benötigte Funktionen definiert und mit Hilfe der Tweet.php lassen sich wenn alle vorherigen Schritte vollendet wurden, Statusmeldungen twittern. Allerdings muss man sagen, dass diese Dateien insgesamt dafür ausgelegt sind mit Hilfe des Terminals die Twitter API zu nutzen. Um die Dateien also auf Webseiten nutzen zu können sind einige Modifizierungen notwendig. Der generelle Ablauf läuft folgender Maßen:

• Zuerst muss in die globals.php wie schon beschrieben der Twitter Consumer Key und das Consumer Secret eingetragen werden
• Als nächstes wird die getreqtok.php ausgeführt. Als Ergebnis erhält man ein Request Token, ein Request Token Secret und einen Link zu Twitter, wo der Nutzer die nötigen Autorisierungsschritte vornehmen kann.
• Der User muss sich auf Twitter nun Anmelden und den Zugriff auf die API gewähren. Als Bestätigung erhält er eine 7 stellige Zahl, welche in die getacctok.php eingetragen werden muss. Zusätzlich muss in die Datei noch das Request Token und das Request Token Secret aus dem Schritt davor eingetragen werden.
• die getacctok.php kann nun ausgeführt werden. Waren die Angaben erfolgreich, erhält man als Antwort das Acces Token, das Acces Token Secret, die User ID des Twitter Nutzers und den Nutzernamen des Twitter Nutzers.
• Das Access Token und das Access Token Secret sind wichtig um jegliche API-Aufrufe durchzuführen, dementsprechend müssen sie für ein Twitter-Post in die tweet.php eingetragen werden. Zusätzlich muss natürlich der Twitter Post in die Datei eingetragen werden.
• Die tweet.php kann nun ausgeführt werden und der User hat einen Post auf Twitter abgegeben.

Da wie an diesen Schritten zu sehen diese Bibliothek für das Terminal ausgerichtet ist, sollte man mit Hilfe von HTML und Javascript Formulare schreiben, in die der Nutzer beispielsweise den Bestätigungscode von Twitter oder die Statusmeldung eintragen kann, welche dann an die PHP-Dateien übergeben werden, zusätzlich benötigt man Automatismen, sodass beispielsweise das Request Token und das Request Token Secret, die man nach erfolgreichem Ausführen der getreqtok.php erhält, direkt in die getacctok.php eingetragen werden. Dies kann man beispielsweise mit Hilfe von Sessions in PHP lösen. Hierzu fügt man unter die Zeile

 logit("getreqtok:INFO:response_body_parsed:");

aus der getreqtok.php folgende Zeilen ein:

 $OAuthRequestToken = $body_parsed[oauth_token];
      $OAuthRequestSecret = $body_parsed[oauth_token_secret];
      SESSION_START();
      $_SESSION["requestToken"] = $OAuthRequestToken;
      $_SESSION["requestTokenSecret"] = $OAuthRequestSecret;

Dadurch wurden die Variablen requestToken und requestTokenSecret belegt und sind in der Datei getacctok.php folgendermaßen zugänglich.

$request_token=$_SESSION["requestToken"];
    $request_token_secret=$_SESSION["requestTokenSecret"];

Die neu belegten Variablen werden später der Funktion get_access_token übergeben, welche dann das Access Token beschafft. Auf die gleiche Weise kann man auch realisieren, dass das Access Token und das Access Token Secret der Datei tweet.php zur Verfügung stehen oder jeder anderen PHP Datei, die auf die Twitter API zugreifen möchte.
Durch diese Schritte ist man in der Lage, die Dateien so zu modifizieren, dass sie über eine Website angesprochen werden können. Man muss lediglich noch die Weiterleitungen vornehmen, sodass man beispielsweise nach dem Ausführen der getreqtok.php den User auf den erhaltenen Link weiterleitet. Zusätzlich wäre es praktisch zu registrieren, ob der User die Seite zum ersten Mal besucht, oder ob er sich schon den Bestätigungscode von Twitter besorgt hat, dies ist beispielsweise mit Hilfe von Cookies oder des LocalStorage in HTML5 möglich.
Als nächstes soll noch gezeigt werden, wie man aufbauend auf der tweet.php jede andere Twitter-API ansprechen kann, sofern man die erforderlichen Rechte auf twitter.com hat. In der Dokumentation der Twitter-API lassen sich alle möglichen Funktionen finden. Im Beispiel wird im folgenden die Datei friends.php erstellt werden, die anzeigen soll, wem der Twitter-Nutzer folgt. Hierzu benötigen wir die Funktion friends/ids welche im Abschnitt Friends&Followers zu finden ist. Die friends.php ist im Prinzip sehr ähnlich aufgebaut wie die tweet.php. Es sind nur wenige Änderungen nötig:

• Als erstes muss natürlich die URL angepasst werden, hierzu ersetzt man

     $url = 'http://api.twitter.com/1/statuses/update.json';
  

  aus der Funktion post_tweet einfach mit der neuen URL in diesem Fall sähe die Zeile also nach der Bearbeitung wie folgt aus:

       $url = 'http://api.twitter.com/1/friends/ids.json';
  

• Der Funktionsname post_tweet wird natürlich angepasst auf in unserem Fall show_friends
• Nun muss man prüfen, ob für die API Abfrage ein Post oder Get nötig ist. Für friends/ids ist GET nötig, daher müssen wir im Vergleich zur post_tweet wieder eine Veränderung vornehmen. Der show_friends Funktion muss dementsprechend als 6. Argument statt true ein false übergeben werden.
• Im letzten Schritt müssen nun noch die Argumente der jeweiligen API-Funktion angeglichen werden. Die Argumente werden innerhalb der show_friends Funktion unter $params definiert. Folgende Zeile ist für die tweet.ph spezifisch gewesen.

  $params['status'] = $status_message;
  

  Da für diese Methode keine weiteren Parameter benötigt werden, löschen wir die obere Zeile und tragen auch keine weiteren Parameter ein.

Mit diesen Schritten wurde nun die friends.php erstellt. Bindet man das Script also auf einer Website ein, beispielsweise über einen Button, kann der Nutzer die User-IDs derjenigen Leute sehen, denen er folgt. Eine PHP-Datei für jede weitere API-Funktion lässt sich analog erstellen.

Fazit

Zusammenfassend aus Beispiel und Tutorial lassen sich folgende Vorteile von OAuth finden:

• Weder Beppa noch die Tutorial Website mussten sich um Login Daten kümmern. Ein Nutzer konnte sich bei einem Service Provider anmelden, ohne dass der Konsument sensible Daten erhalten hat
• Im Idealfall kann der Nutzer selbst entscheiden, welche Rechte er Drittanbietern gibt. In jedem Fall aber muss er Apps oder Websiten klar autorisieren, bevor diese auf seine Daten zugreifen können
• Die Autorisierung kann jeder Zeit wieder rückgängig gemacht werden, worauf die Access Token der Consumer an Gültigkeit verlieren
• Der Service Provider weiß zwar welche Dienste der User wann von den Consumern angenommen hat, jedoch erhält er nicht mehr Informationen als er sowieso schon hat, da der Service Provider Informationen ja bereit stellt und keine selbst erhält
• OpenID und OAuth lassen sich theoretisch auch gemeinsam nutzen. Hierbei leitet der Service Provider den Nutzer zu Authentifizierung lediglich an einen OpenID Provider weiter.

Nachteilig kann man feststellen, dass auch OAuth keinerlei Sicherheitsanforderungen bezüglich der Authentifizierung stellt. Da das obige Beispiel sich nur mit dem Nutzen von einer vorhanden API eines Service Providers beschäftigt, ist noch hinzuzufügen, dass es auch möglich ist OAuth Service Provider zu werden, hierfür gibt es beispielsweise eine Ruby- oder PHP-Bibliothek.