20.3. Authentifizierung

Grundsätzlich werden über den Aufruf

GET http://test.local/wp-json

alle Routen und Endpunkte zurückgegeben. Auch die, die man zum Beispiel zum Löschen eines Beitrags verwenden kann.

Das bedeutet allerdings nicht, dass man diese Endpunkte auch erfolgreich ansteuern kann.

Die Anfrage an:

DELETE http://test.local/wp-json/wp/v2/posts/1

endet unweigerlich in folgender Rückgabe:

{
    "code": "rest_cannot_delete",
    "message": "Du bist leider nicht berechtigt, diesen Beitrag zu löschen.",
    "data": {
        "status": 401
    }
}

Das klappt nur nach einem Login.

Cookie-Authentifizierung

WordPress bietet zum aktuellen Stand nur die Cookie-Authentifizierung. Das heißt, ein Benutzer muss bei WordPress (über die Administrationsoberfläche) angemeldet sein um API-Anfragen senden zu können.

Dieser Inhalt ist nur eingeschränkt verfügbar. Melden Sie sich vorher an.

Nonce über den Header senden

Mit jQuery lässt sich die Nonce über einen zusätzlichen Header wie folgt senden:

Dieser Inhalt ist nur eingeschränkt verfügbar. Melden Sie sich vorher an.

Hinweis
Die globale Variable wpApiSettings existiert nur, wenn Ihr Script vom Handle wp-api-request abhängig ist. Erfahren Sie mehr zum Thema Script-Abhängigkeiten im Kapitel über CSS- und JavaScript-Dateien.

Nonce über einen Parameter senden

Alternativ kann man den Parameter _nonce nutzen:

Dieser Inhalt ist nur eingeschränkt verfügbar. Melden Sie sich vorher an.

Authentifizierung mit Benutzername und Passwort

Es existiert ein so genanntes Basic-Authentification Plugin, welches man auf Github finden kann. Es erlaubt die Nutzung der REST-API mittels Benutzername und Passwort. Das bedeutet: diese zwei Daten müssen mit jedem Request mitgeschickt werden.

Aus Sicherheitsgründen empfiehlt WordPress die Nutzung nur für Entwicklungszwecke. Ich werde deshalb nicht näher darauf eingehen.

Authentifizierung mit OAuth

Neben dem Basic-Auth-Plugin existiert auch ein OAuth-Server-Plugin welches mit dem OAuth 1.0a Protokoll arbeitet. Das heißt, man kann sich API-Schlüssel selbst ausstellen und diese dann für die Anfragen verwenden.

Die Anfragen verlaufen dann in der Regel so:

  1. Der Client sendet den API-Schlüssel signiert an einen speziellen REST-Endpunkt.
  2. Dieser Endpunkt antwortet im Erfolgsfall mit einem so genannten Request Token.
  3. Dieser Token kann dann für die richtigen Anfragen genutzt werden.

Der gesamte Vorgang kann noch etwas komplizierter werden, wenn ein Benutzer explizit Freigaben erteilen soll. Dann wird der Browser involviert und zeigt zuvor einen Freigabe-Bildschirm an. Der gesamte Ablauf kann z.B. hier nachgelesen werden: http://oauthbible.com/ (englisch).

2009 wurde in OAuth 1 eine Sicherheitslücke entdeckt, die in Version 1.0a geschlossen wurde. Nichts desto trotz gilt OAuth1 eher als unsicher.

Ein OAuth 2.0 Plugin existiert ebenfalls. Es hat allerdings den Nachteil, dass es zwingend eine SSL-Verschlüsselung vorschreibt, SSL aber nicht standardmäßig auf jedem Host verfügbar ist. Das könnte sich allerdings in naher Zukunft ändern. Denn immer mehr Webseitenbetreiber werden über die neue Datenschutzgrundverordnung (DSGVO) dazu gezwungen, ein SSL-Zertifikat nachzurüsten.

Authentifizierung über Application-Passwords

Das Application-Passwords-Plugin funktioniert ähnlich wie das Basic-Auth-Plugin. Allerdings schränkt es den Zugriff ein indem man für jeden Zweck einen einzelnen Benutzer erstellt. Diesen Benutzern können dann entsprechende Rechte gegeben oder eben nicht gegeben werden.

Authentifizierung mit JSON Web Tokens

Auch für gibt es ein spezielles Plugin. Hier nutzt man ein nach RFC 7519 genormtes Access-Token für den Zugriff auf die REST-API.

Was denn nun?

Wenn man nur interne Funktionen z.B. im Front- oder Backend per JavaScript über ein Plugin nachrüsten will, benötigt man kein weiteres Authentifizierung-Plugin. Denn es reicht in der Regel aus, dass der Benutzer an- oder angemeldet. Lediglich die Nonce muss man zusätzlich übermitteln. Und sogar das übernehmen einschlägige JavaScript Funktionen, die von WordPress mitgeliefert werden. Ich werde Ihnen das in einem Beispiel später zeigen.

Ansonsten kommt es natürlich auf den Verwendungszweck an. Persönlich würde ich auf OAuth 2.0 setzen. Es ist die gängige Variante die auch von den „Großen“ (Twitter, Facebook, Google) verwendet wird. Auch das bereitgestellte Plugin wird – so wie es scheint – fleißig aktualisiert.

❬ 20.2. Nützliche Funktionen der REST-API20.4. Die REST-API erweitern ❭