Wie Sie OAuth zur Autorisierung verwenden
Kommentare

Je nach Informationsbedarf können Sie weitere Daten abfragen und speichern, zum Beispiel den Namen und eine Beschreibung des Consumers und dessen Callback-Endpunkt sowie Informationen über den Entwickler.

Je nach Informationsbedarf können Sie weitere Daten abfragen und speichern, zum Beispiel den Namen und eine Beschreibung des Consumers und dessen Callback-Endpunkt sowie Informationen über den Entwickler.

Eine minimale Tabelle für die Speicherung könnte wie in Tabelle 1 aussehen. Sie müssen nun eine Seite erstellen, auf der die Entwickler ihre Anwendungen anmelden können, woraufhin Sie ihnen den von Ihrer Webanwendung erzeugten Consumer Key und das zugehörige Consumer Secret mitteilen.

In Ihrem eigenen Interesse sollten Sie auch Funktionen zum Aktualisieren der Informationen und zum Löschen der Consumer vorsehen, damit Ihre Webanwendung später nicht unnötigerweise Karteileichen mit längst nicht mehr existierenden Consumern mit sich herumschleppt.

Feld Type Null Key Default Extra
id int NO PRI NULL auto_increment
consumer_key varchar(30) NO NULL
consumer_secret varchar(10) NO NULL
created Timestamp NO CURRENT_TIMESTAMP

Tabelle 1: Die Tabelle für die OAuth Consumer

2. Der Endpunkt für die Anforderung der Temporary Credentials (Schritt 1)

Für die Endpunkte wird immer der gleiche Constructor-Code verwendet (Listing 2). Besonders wichtig ist dabei die Funktion setRequestTokenPath(): Das ist die einzige Funktion beziehungsweise der einzige URL, auf die/den ohne gültige Token Credentials zugegriffen werden kann. Die Callback-Funktionen erfüllen folgende Aufgaben:

Listing 2
$this->provider = new OAuthProvider();

// Namen der Callback-Funktionen:
$this->provider->consumerHandler(array($this,'lookupConsumer'));
$this->provider->timestampNonceHandler(array($this,'timestampNonceChecker'));
$this->provider->tokenHandler(array($this,'tokenHandler'));

// URL, die ohne Token Credentials aufgerufen werden kann, 
// um die Token Credentials anzuforndern: 
$this->provider->setRequestTokenPath('/pfad/zu/request_token');
 
// Prüfen, ob der Request gültig ist:
$this->provider->checkOAuthRequest();
  • lookupConsumer() prüft, ob Consumer Key und Consumer Secret gültig sind
  • timestampNonceChecker() prüft ggf., ob sich der Zeitstempel im gültigen Bereich befindet. Außerdem wird zur Abwehr von Replay-Angriffen geprüft, ob der Nonce bereits verwendet wurde.
  • tokenHandler() prüft, ob die Token Credentials korrekt sind.
Listing 3
public function lookupConsumer($provider) {
   // 1. Consumer Secret z.B. aus der Datenbank holen
   // Vorsicht: SQL-Injection-Gefahr!
   $consumer_key = $provider->consumer_key;
   $sql = 'SELECT consumer_secret FROM oauth_consumers WHERE consumer_key ='.$consumer_key;
   $consumer_secret = [Ergebnis der SQL-Abfrage]
   // 2. Consumer Secret prüfen:
   if($provider->consumer_secret == $consumer_secret) {
      return OAUTH_OK;
   } else {
      return OAUTH_CONSUMER_KEY_UNKNOWN;
   }
}

Die Funktion lookupConsumer() könnte wie in Listing 3 aussehen. Für die Prüfung des Consumer_Secret gibt es als weiteren möglichen Rückgabewert OAUTH_CONSUMER_KEY_REFUSED zur Kennzeichnung unerwünschter Consumer Keys, zum Beispiel jener, die gesperrt oder noch nicht freigegeben wurden. Die Funktion timestampNonceChecker() können Sie frei an Ihre Anforderungen anpassen. Alles von einer aufwendigen Prüfung von Zeitstempel und Nonce bis zur einfachen Rückgabe von OAUTH_OK beim Aufruf ist möglich.

Je aufwändiger die Funktion, desto schwieriger sind Replay-Angriffe. Besteht bei Ihrer Webanwendung keine Gefahr durch Replay-Angriffe, können Sie einfach immer durch Rückgabe von OAUTH_OK Alles OK melden. Je gefährlicher ein Angriff ist, desto höhere Anforderungen sollten Sie an den Zeitstempel beziehungsweise das gültige Zeitfenster stellen.

Üblich sind Werte von einigen Minuten rund um die aktuelle Serverzeit. Beim Prüfen des Nonce ist die Prüfung dagegen einfach: Entweder er wurde bereits verwendet oder nicht. Hier liegt die Anforderung bei der Erzeugung des Nonces: Je leichter er vorhersagbar ist, desto leichter fallen auch Angriffe. Die FunktiontokenHandler()wird später beschrieben, jetzt folgt erst mal der Code zum Erzeugen der Temporary Credentials (Request Token). Der kann wie in Listing 4 aussehen. Die Tabelle zur Speicherung der Temporary Credentials könnte wie in Tabelle 2 aussehen.

Listing 4
// Da Token und Secret Binärdaten sind, müssen sie z.B. in Hex umgewandelt
// oder URL-kodiert werden:
$request_token = bin2hex($this->provider->generateToken(4));
$request_token_secret = bin2hex($this->provider->generateToken(12));

// Request Token und Secret müssen z.B. in der Datenbank gespeichert werden 
...

// Jetzt muss der URL zum Autorisieren erzeugt und ausgegeben werden:
echo 'login_url=http://webanwendung.example/autorisierung.php?request_token='.$request_token.'&request_token_secret='.$request_token_secret.'&oauth_callback_confirmed=true';
Feld Type Null Key Default Extra
id int NO PRI NULL auto_increment
consumer_key varchar(30) NO NULL
request_token varchar(8) NO NULL
request_token_secret varchar(32) NO NULL
callback varchar(500) NO NULL
verifier varchar(20) NO NULL
authorised_user_id int NO NULL
created Timestamp NO CURRENT_TIMESTAMP

Tabelle 2: Die Tabelle für die Temporary Credentials

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -