In unserem Beispiel ist Alice der User, Bitly der OAuth Consumer und Facebook der OAuth Provider, auf dem sich die sichere Ressource von Alice befindet (ihr Facebook-Profil). Alice möchte sich bei Bitly mit ihren Facebook-Daten registrieren. So funktioniert’s:

Schritt 1: Der User äußert seine Absicht

Alice (Nutzer): ”Hi Bitly, ich möchte, dass du alle Information die du zur Registrierung brauchst aus meinem Facebook Profil holst.“
Bitly (OAuth consumer): “Super! Ich bitte gleich um die Genehmigung.”

Schritt 2: Der Consumer erhält die Genehmigung

Bitly: „Facebook, ein User möchte, dass ich seine Profil-Daten für eine Registrierung abfrage . Kann ich einen Abfrage-Token haben?“
Facebook (OAuth Provider): „Natürlich. Hier sind ein Token und ein Geheimnis.“

Das Geheimnis wird benötigt, um gefälschte Abfragen zu verhindern. Der Consumer verwendet das Geheimnis, um jede Abfrage zu signieren. So kann der Service Provider überprüfen, ob die jeweilige Abfrage auch wirklich von der Consumer-Anwendung kommt.

Schritt 3: Der User wird zum Service Provider weitergeleitet

Bitly: „OK, Alice. Ich leite dich jetzt an Facebook weiter, damit du die Aktion bestätigen kannst. Nimm diesen Token mit.“

Wäre Bitly ein unseriöser Anbieter, könnte er ein Popup-Fenster verwenden, das zwar genau wie Facebook aussieht, aber eigentlich eine Phishing-Seite ist, mit dem er die Zugangsdaten von Alice in Erfahrung bringen kann. Stellen Sie stets sicher, dass es sich bei der URL, an die Sie weitergeleitet werden, wirklich um den Service Provider handelt (in diesem Fall Facebook).

Schritt 4: Der User gibt seine Erlaubnis

Alice: „Facebook, ich möchte diesen Abfrage-Token autorisieren, den Bitly mir gegeben hat.“
Facebook: „OK. Nur zur Sicherheit: Du möchtest Bitly die Erlaubnis dazu geben, auf folgende Daten deines Facebook Kontos zuzugreifen? Emailadresse, Name etc..“
Alice: „Ja!“
Facebook: „OK. Du kannst zu Bitly zurückkehren und ihm sagen, dass er seinen Abfrage-Token jetzt verwenden kann.“

Schritt 5: Der Consumer erhält einen Zugangs-Token

Bitly: „Facebook, kann ich diesen Abfrage-Token gegen einen Zugangs-Token tauschen?“
Facebook: „Sicher. Hier sind der Zugangs-Token und das Geheimnis.“

Schritt 6: Der Consumer greift auf die geschützte Ressource zu

Bitly: „Ich möchte gern die Profildaten von Alice haben. Hier ist mein Zugangs-Token!“
Facebook: „Hier sind die Daten von Alice …“

Consumer Anmeldedaten

Der Consumer muss zuvor beim Provider registriert werden. In der Regel müssen grundlegende Informationen beim Provider hinterlegt werden, wie Anwendungsname, Webseite etc. Darüber hinaus muss für Web-Server, Browser-basierte oder mobile Anwendungen eine URI (TLS gesichert) registriert werden, welche den Benutzer nach erfolgreicher Bestätigung beim Provider zurück zum Consumer leitet. Nach der Registrierung des Consumers, erhält man üblicherweise die öffentliche Client ID und ein Geheimnis. Diese Daten werden unter anderem dafür genutzt um API-Zugriffsrechte auf Seiten des Providers zu steuern.

Der erste Schritt des OAuth2 Autorisierung ist die Genehmigung des Benutzers zu erhalten. Für Browser-basierte oder mobile Anwendungen wird dies in der Regel durch die Anzeige eine Schnittstelle mit dem Service für den Nutzer erreicht. OAuth 2 bietet hierfür einige „Grant Types“ für verschiedene Anwendungsfälle:

Berechtigungscode

Beim Berechtigungscode loggt sich der Benutzer beim OAuth Provider ein und gibt seine Daten frei. Mit dem Zurückleiten zum Consumer schickt der Provider einen Berechtigungscode. Dieser fungiert gemeinsam mit der Client-ID und dem entsprechenden Passwort als Zugangsdaten. Auf Basis dieser Informationen stellt der OAuth Provider ein Zugangstoken bzw. Access-Token aus.

Implicit

Die implizite Berechtigung unterscheidet sich nur unwesentlich vom Zugang über den Berechtigungscode, ist allerdings im Kommunikationsprozess weniger aufwändig. Nach dem Einloggen in den OAuth Provider erhalten Sie direkt den Autorisierungscode samt Zugangstoken.

Passwort

Passwortfreigabe durch den Besitzer der Daten: In diesem Fall würden Sie dem Consumer direkt die Zugangsdaten zum Provider überlassen. Dieses Verfahren ist sehr risikobehaftet und erfordert ein hohes Maß an Vertrauen gegenüber dem Consumer.

Client Credentials

Dieses Szenario wird eingesetzt, wenn die Consumer-Anwendung Zugriff auf Informationen auf dem OAuth Provider benötigt, die keinen Besitzer haben.

Most OAuth implementations are based on the OAuth2.0 Bearer-token (RFC Standard). The OAuth2.0 Bearer-token profile offers a simplified regulation for authentication.

Die meisten OAuth Implementierungen basieren auf dem OAuth 2.0 Bearer-Token (RFC Standard). Das OAuth 2.0 Bearer Token-Profil bringt eine vereinfachte Regelung für die Authentifizierung. Diese Spezifikation beschreibt, wie Bearer (=Inhaber) Token in HTTP-Anfragen zu nutzen sind, damit auf OAuth 2.0 geschützte Ressourcen zugegriffen werden kann. Der Bearer-Token muss über SSL/TLS gesichert werden, wenn also HTTPS keine Option ist, dürfen Bearer-Token nicht verwendet werden. Stattdessen können MAC-Token genutzt werden. Primäres Ziel des MAC-Tokens ist es, die HTTP-Authentifizierung zu sichern, wenn SSL/TLS nicht genutzt werden kann.

OAuth 2.0 hat im Wesentlichen drei Phasen:

1. Genehmigung anfordern (Authorization Grant)
2. Austausch des Authorization Grant für einen Access-Token
3. Zugriff auf die Ressourcen mit dem Access-Token

Wo kommt also der Token-Typ zum Einsatz?

Beispiel für eine Antwort mit dem Access-Token (Bearer):

HTTP/1.1 200 OK
  Content-Type: application/json;charset=UTF-8
  Cache-Control: no-store
  Pragma: no-cache
  {
  "access_token":"mF_9.B5f-4.1JqM",
  "token_type":"Bearer",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
  }

Der access_token identifiziert den MAC Schlüssel (=MAC-Schlüssel-ID), welcher dazu verwendet wird, den MAC-Wert der Anfrage zu berechnen. Der eigentliche Schlüssel bleibt dem Consumer, im Gegensatz zum Bearer-Token-Profil, verborgen. Der Server weist typischerweise eine bestimmte Laufzeit zu jedem Satz von MAC-Anmeldeinformationen.

Beispiel für eine Antwort mit dem Access-Token (Mac):

HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: no-store
  {
  "access_token":"SlAV32hkKG",
  "token_type":"mac",
  "expires_in":3600,
  "refresh_token":"8xLOxBtZp8",
  "mac_key":"adijq39jdlaska9asud",
  "mac_algorithm":"hmac-sha-256"
  }

Der MAC-Zugriffstoken hat zwei zusätzliche Attribute: mac_key und mac_algorithm. Der mac_key ist ein gemeinsamer symmetrischer Schlüssel, mac_algorithm beschreibt den zu nutzenden Algorithmus.

Mit dem Bearer-Token muss lediglich der Access-Token vom Autorisierungsserver aus Schritt 2 übergeben werden:

Authorization: Bearer mF_9.B5f-4.1JqM

Beim MAC-Token-Profil muss der Consumer ein paar mehr Informationen mit auf den Weg schicken:

Authorization: MAC id="h480djs93hd8",
ts="1336363200",
nonce="dj83hs9s",
mac="bhCQXTVyfj5cmA9uKkPFx1zeOXM="

1. id ist die MAC Schlüssel Kennung bzw. der Access-Token aus Schritt 2
2. ts ist der Zeitstempel der Anfrage (verstrichene Sekunden ausgehend von einem fixen Zeitpunkt, Integer). Dieser Wert ist einzigartig unter allen Anfragen mit dem gleichen Zeitstempel und Mac Schlüssel Kennung
3. Nonce ist eine eindeutige Zeichenfolge, die vom Consumer generiert wird. Der Wert ist einzigartig in allen Anfragen mit dem gleichen Zeitstempel und MAC-Schlüssel-ID -Kombination
4. mac wird vom Consumer aus dem MAC Algorithmus und des MAC Schlüssels berechnet

Der mac Wert ist eine konstante, reproduzierbare Verkettung von mehreren HTTP-Anfrage-Elementen in einem einzigen String. Er wird aus folgenden Informationen berechnet: Zeitstempel der Anfrage, dem nonce Wert, der HTTP-Anfragemethode (HEAD,GET, POST etc.), die HTTP Anfrage URI (definiert in RFC2616 Punkt 5.1.2.), Hostname, Port, Wert des optionalen request header field attribute „ext“.

Jedes dieser Elemente wird gefolgt von einem Zeilenvorschubzeichen (%x0A). Anschließend wird der String mit Hilfe des unter mac_algorithm angegebenen Algorithmus gehasht.

Die Implementierung mit dem MAC-Token-Verfahren ist um einiges aufwändiger für den Consumer als auch für den OAuth Provider. Das Profil stellt aber eine Methode zur Verfügung, wenn der Schlüssel nicht direkt, wie beim Bearer-Token Verfahren, übertragen werden kann. Ist eine Übertragungssicherheit mittels SSL/TLS gewährleistet, wird meist der simple Bearer-Token bevorzugt..

In unserem Beispiel musste Alice ihre Facebook-Zugangsdaten gegenüber Bitly nie preisgeben. Sie delegierte den Zugang einfach auf sichere Weise über OAuth. Alice kann sich jederzeit bei Facebook anmelden, die von ihr erteilten Zugangsrechte überprüfen und Tokens für bestimmte Anwendungen aufheben, ohne dadurch andere zu beeinträchtigen.

OAuth ermöglicht zudem detaillierte Berechtigungsstufen. So kann sie beispielsweise Bitly die Berechtigung erteilen, auf Ihrem Facebook-Konto zu posten, den Zugriff auf LinkedIn jedoch auf „Nur lesen“ beschränken.

OAuth ist eine robuste Lösung für browserbasierte Anwendungen und eine enorme Verbesserung gegenüber der HTTP Basic Authentication. Allerdings gibt es auch bei OAuth einige Stolperfallen in der Entwicklung des Consumers oder des Providers, welche das System verletzlich und angreifbar machen.

Im Normalfall hat die Third-Party-App bzw. der Consumer niemals Zugriff auf die Login-Credentials des Nutzers auf dem Provider. Trotzdem können unter Umständen aber sehr sensible Nutzerdaten übertragen werden. Ein Beispiel für die Übertragung solcher Daten wäre eine Bank-App. Es können Kontonummern, Adressen und Transaktionen eingesehen werden oder Transaktionen gestartet werden. Bei diesen Informationen muss erstens sichergestellt werden, dass die Übertragung abgesichert ist und die App diese Informationen nicht speichert. Zweitens muss der Provider dem Consumer, bzw. der App vertrauen, dass der Zugriff auf diese Daten nicht missbraucht wird. Sobald der Provider die Daten herausgibt, hat er keine Möglichkeit mehr die sensiblen Daten zu kontrollieren, was evtl. auch rechtlich ein Problem darstellen kann.

Eine unseriöse App könnte also die gesammelten Adressen verkaufen, Kontonummern weitergeben und Transaktionen auswerten, auch wenn die Login-Daten nicht bekannt sind. Es ist aus Provider-Sicht somit nicht sonderlich sinnvoll, Consumern dynamisch bzw. automatisch den Zugriff auf die API zu erlauben. Consumer müssen sich vor den ersten API Anfragen händisch am Provider registrieren und spezifische Callback URI’s vergeben. Nach Prüfung erhält der Consumer dann die Consumer-Credentials vom Provider und kann Anfragen an die API stellen.

Besonders weil OAuth sich nur um die Autorisierung kümmert, jedoch auch mit der Authentifizierung in Berührung kommt kann es zu Attacken auf die Nutzerdaten kommen. Ein unseriöser Consumer kann mittels Phishing versuchen an die Provider-Zugangsdaten der Nutzer zu kommen. Der Provider kann hier ganz einfach eine Zwei-Faktor Authentifizierung einführen um passwortbasierte Zugangsdaten zu unterbinden (siehe 4). Das Fehlen eines optionalen Parameters (’state‘ mit Random-Hash) kann dazu führen, dass mittels CSRF (Cross-Site-Request-Forgery) Benutzerkontos des Providers übernommen werden können. Da der Parameter optional ist, wird er oft nicht mit berücksichtigt. Um „Covert Redirects“ oder offene Redirects zu verhindern, muss der Provider die Callback-URL prüfen, ob diese zuvor vom Consumer registriert wurde.

Bei der Entwicklung eines OAuth Providers ist es daher wichtig mögliche Exploits zu verhindern um die Ressourcen und Nutzerkonten vor Missbrauch zu schützen.

Um mögliche Phishing Attacken zu verhindern setzen wir zur Authentifizierung am Provider die SecSign ID Zwei-Faktor Authentifizierung ein

OAuth ist ein guter Standart um Drittanbietern Zugriff auf Ressourcen zu gewähren. OAuth regelt dabei aber nur die Autorisierung, nicht die Authentifizierung.

Für den Provider mit einer passwortbasierten Authentifizierung kann dies gefährlich werden, wenn ein unseriöser Consumer versucht, unvorsichtigen Nutzern die Zugangsdaten für den Provider zu stehlen. Dazu muss der Consumer nur den OAuth Vorgang vortäuschen und ein Popup-Fenster verwenden das zwar genau wie der Provider (zum Beispiel Facebook) aussieht, aber eigentlich eine Phishing-Seite ist. Passt der Nutzer nicht auf, gibt er seine Facebook Zugangsdaten ein und sendet diese direkt an den Consumer. Der Nutzer muss also stets sicherstellen, dass es sich bei der URL an die er weitergeleitet wird, wirklich um den Provider handelt (in diesem Fall Facebook).

Das Problem kann umgangen werden, indem der Provider eine echte Zwei-Faktor Authentifizierung (z.B. SecSign ID) anbietet. Die passwortlose Anmeldung schützt die Nutzer vor dem möglichen Diebstahl der Zugangsdaten. SecSign löst die Passwortprobleme unter Zuhilfenahme einer Challenge-Response- Authentifizierung mit 2048-Bit RSA-Schlüsselpaaren. Passwörter werden somit überflüssig und sensible Benutzerdaten werden weder übertragen noch gespeichert. Das bedeutet, dass Hacker keine Gefahr mehr für Benutzerkonten darstellen, da schlicht und ergreifend keine Passwörter gestohlen werden können.

Die Zwei-Faktor-Authentifizierungsmethode arbeitet dabei mit dem mobilen Gerät des Nutzers (also etwas, das sich in seinem Besitz befindet) und dem Wissen des Nutzers (der PIN zur Identitätsüberprüfung). Der Nutzer gibt für die Anmeldung am Provider lediglich seinen in der SecSign App selbstgewählten Benutzernamen an und bekommt ein Symbol angezeigt. Der Nutzer wählt dann seine SecSign ID in der App aus und gibt eine PIN ein. Durch die Auswahl des richtigen Symbols in der App wird der User bei dem gewünschten Provider angemeldet.

Im folgenden werden wir ein Beispiel implementieren welches folgendes Szenario darstellt:

• Website A / OAuth Provider: die Website, auf die der Zugriff erlaubt werden soll. Jeder User hat ein persönliches Profil und kann eine Notiz speichern.
• Website B / OAuth Consumer: die Anwendung ermöglicht es Notizen zu veröffentlichen. Der Consumer bietet dafür die Möglichkeit die Notiz von Website A abzufragen und zu veröffentlichen.

Wie kommt Website B nun an die Daten des Nutzers von Website A, ohne Nutzernamen und Passwort zu verlangen? Hier kommt OAuth ins Spiel. OAuth macht es möglich, dass Website B auf die (per API zur Verfügung gestellten) Daten von Website A zugreifen kann ohne das der Benutzer jemals seine Login-Credentials für A an B geben muss.

Die folgenden Hinweise geben einen Anhaltspunkt, wie Sie einen OAuth2 Server bzw. OAuth Provider realisieren.

Um Phishing Attacken zu verhindern setzen wir zur Authentifizierung am Provider die SecSign ID Zwei-Faktor Authentifizierung ein. Des weiteren wird die Session am Consumer gehasht und als state Variable an den Provider gegeben um CSRF Attacken zu unterbinden.

Unser Beispiel bezieht sich auf eine lokale Testumgebung für den Provider und Consumer. Da die integrierten PHP Server Single Threaded sind, müssen 2 Instanzen erzeugt werden damit Provider und Consumer gleichzeitig kommunizieren können.

Bitte beachten Sie, dass wir in diesem Beispiel Bearer-Token verwenden, welche mittels SSL/TLS abgesichert sein müssen. Bei einem lokalen Test können wir dies vernachlässigen, eine Produktiv-Umgebung dagegen muss entsprechende Sicherheitsmaßnahmen treffen und die, unter Anderem, Kommunikation per SSL/TLS oder MAC-Token absichern.

Der Artikel erklärt die notwendigen Schritte und Dateien, um einen OAuth Provider mit 2FA und einen OAuth Consumer zu entwickeln und zu testen.

Erstellen Sie einen neuen Ordner für den Provider und starten Sie den Webserver:

mkdir oauth2-secsign
cd oauth2-secsign
mkdir secsign-provider
mkdir secsign-consumer
cd secsign-provider
php -S localhost:8088

Öffnen sie eine neue Konsole / Terminal und erzeugen sie eine neue Webserver Instanz für den Consumer:

cd oauth2-secsign/secsign-consumer
php -S localhost:8089

Für die weiteren Schritte wird Composer vorausgesetzt. Composer ist ein Paketmanager für PHP und installiert Abhängigkeiten (zum Beispiel: Bibliotheken) eines PHP-Programmes.

Die folgenden Hinweise geben einen Anhaltspunkt, wie Sie einen OAuth2 Server bzw. OAuth Provider realisieren. Wir nutzen die OAuth2-server-php PHP library , welche uns alle Funktionen etwas bequemer zur Verfügung stellt. Falls sie lieber eine andere Bibliothek oder andere Serversprache nutzen möchten, gibt es hier eine Übersicht.

1. Abhängigkeiten installieren und Datenbank vorbereiten

Mittels composer install werden alle Abhängigkeiten installiert. Dies sind OAuth2-server-php sowie secsignphphelper, welcher ohne großen Aufwand eine Zwei Faktor Authentifizierung erlaubt.

Wechseln sie in das Verzeichnis secsign-provider und erstellen sie composer.json:

{
  "repositories": [
    {
      "type": "vcs",
      "url": "https://github.com/SecSign/secsignphphelper",
      "minimum-stability":"dev"
    }],
  "require" : {
    "SecSign/secsignphphelper": "*",
    "bshaffer/oauth2-server-php": "~1.8"
  }
}

Nutzen Sie das folgende Schema um die Standarddatenbank (MySQL, SQLite, PostgreSQL oder MS SQL Server) zu erstellen :

CREATE TABLE oauth_clients (client_id VARCHAR(80) NOT NULL, client_secret VARCHAR(80), redirect_uri VARCHAR(2000) NOT NULL, grant_types VARCHAR(80), scope VARCHAR(100), user_id VARCHAR(80), CONSTRAINT clients_client_id_pk PRIMARY KEY (client_id));
CREATE TABLE oauth_access_tokens (access_token VARCHAR(40) NOT NULL, client_id VARCHAR(80) NOT NULL, user_id VARCHAR(255), expires TIMESTAMP NOT NULL, scope VARCHAR(2000), CONSTRAINT access_token_pk PRIMARY KEY (access_token));
CREATE TABLE oauth_authorization_codes (authorization_code VARCHAR(40) NOT NULL, client_id VARCHAR(80) NOT NULL, user_id VARCHAR(255), redirect_uri VARCHAR(2000), expires TIMESTAMP NOT NULL, scope VARCHAR(2000), CONSTRAINT auth_code_pk PRIMARY KEY (authorization_code));
CREATE TABLE oauth_refresh_tokens (refresh_token VARCHAR(40) NOT NULL, client_id VARCHAR(80) NOT NULL, user_id VARCHAR(255), expires TIMESTAMP NOT NULL, scope VARCHAR(2000), CONSTRAINT refresh_token_pk PRIMARY KEY (refresh_token));
CREATE TABLE oauth_users (user_id INT NOT NULL AUTO_INCREMENT, secsignid VARCHAR(255) NOT NULL, first_name VARCHAR(255), last_name VARCHAR(255), PRIMARY KEY (user_id));
CREATE TABLE oauth_scopes (scope TEXT, is_default BOOLEAN);
CREATE TABLE oauth_jwt (client_id VARCHAR(80) NOT NULL, subject VARCHAR(80), public_key VARCHAR(2000), CONSTRAINT jwt_client_id_pk PRIMARY KEY (client_id));
CREATE TABLE oauth_content (user_id INT NOT NULL, note TEXT);

INSERT INTO oauth_clients (client_id, client_secret, redirect_uri) VALUES ("consumer1", "c1pass", "http://localhost:8089");
INSERT INTO oauth_users (secsignid, first_name, last_name) VALUES ("PUT_YOUR_SECSIGNID_IN_HERE", "John", "Doe");
INSERT INTO oauth_content (user_id, note) VALUES ("1", "Hi, this is my note saved on the provider.");

2. OAuth2 Server

Nun müssen wir unser OAuth2 Server-Objekt erstellen und konfigurieren. Das Server-Objekt wird von allen Endpunkten in unserer Anwendung verwendet.

server.php :

<?php
// change the following parameter according to your database settings
// $dsn is the name for the data source of your data base, for example "mysql:dbname=my_oauth2_db;host=localhost"
$dsn      = 'mysql:dbname=my_oauth2_db;host=localhost';
$username = 'root';
$password = '';
// Vendor directory, composer should copy all dependencies in this directory
$extPath = "http://localhost:8088/vendor";
// ativate error reporting 
ini_set('display_errors',1);error_reporting(E_ALL);
OAuth2\Autoloader::register();
$storage = new OAuth2\Storage\Pdo(array('dsn' => $dsn, 'username' => $username, 'password' => $password));
// hand the memory object to the OAuth2 server class
$server = new OAuth2\Server($storage);
// Add the "client credentials" grand type
$server->addGrantType(new OAuth2\GrantType\ClientCredentials($storage));
// Add the "authorization code" grant type
$server->addGrantType(new OAuth2\GrantType\AuthorizationCode($storage));

3. Token Controller

Als nächstes erstellen wir den Token Controller. Diese URI gibt einen Token an den Consumer zurück.

token.php:

<?php
// OAuth2 server object
require_once __DIR__.'/server.php';
// regulates the request for an OAuth2.0 access token and forwards the response to the consumer
$server->handleTokenRequest(OAuth2\Request::createFromGlobals())->send();
?>

Beim Erstellen der Datenbank wurde bereits ein neuer OAuth Consumer bzw. OAuth Client (consumer1) beim Provider registriert.

curl -u consumer1:c1pass http://localhost:8088/token.php -d ‘grant_type=client_credentials’

Ein Access-Token sollte erhalten werden:

{"access_token":"0b4dfae9cdf6c777d4dfae9c0d3807cb3903193293b3c35","expires_in":3600,"token_type":"bearer","scope":null}

4. Resource Controller

resource.php:

<?php
// OAuth2sServer object
require_once __DIR__.'/server.php';
// Handle a request to a resource and authenticate the access token
if (!$server->verifyResourceRequest(OAuth2\Request::createFromGlobals())) {
    $server->getResponse()->send();
    die;
} else {
    // find access token and fetch user ID
    $token = $server->getAccessTokenData(OAuth2\Request::createFromGlobals());
    $userId = $token['user_id'];
    if($userId){
        //find note
        $result='';
        $db = new \PDO($database['dsn'], $database['username'], $database['password']);
        try {
            $stmt = $db->query('SELECT * FROM oauth_content');
            $result = $stmt->fetch(PDO::FETCH_OBJ);
        } catch(PDOException $ex) {
            echo "Database error";
        }
        echo json_encode(array('id' => $result->user_id, 'note' => $result->note));
    } else {
        echo json_encode(array('message' => 'access_code is not valid to request a note'));
    }
}

Jetzt wo wir Tokens erstellen können, wollen wir sie auch validieren

Der Resource Controller ist für die Ausgabe der Notizen zuständig. Im nächsten Schritt erstellen wir den Controller für die Autorisierung, welcher bei einer erfolgreichen Anmeldung dem Consumer einen dem Nutzer eindeutigen Code zurück gibt. Der Consumer kann nun mit seinen Credentials und dem Code des Nutzers einen Token anfordern. Geht alles gut, erhält der Consumer vom Token Controller einen Access Token. Dieser Access Token wird an den Resource Controller gesendet um die Notiz abzurufen. Der Resource Controller validiert den Token und sieht nach, ob ein Benutzer mit dem Token verknüpft ist. Wenn alles stimmt, wird die Notiz zum Consumer gesendet.

5. Controller für die Authorisierung

Der Controller zur Autorisierung ermöglicht den Benutzern, Anwendungen von Drittanbietern zu genehmigen. Statt den Access Token direkt zu vergeben (wie im ersten Token-Controller Beispiel) wird hier der Authorize-Controller verwendet, um nur dann ein Token ausgeben, wenn der Benutzer die Anforderung genehmigt hat.

authorize.php:

<?php
// OAuth2 Server object and SecSignHelper
require_once __DIR__.'/server.php';
require_once __DIR__.'/vendor/secsign/secsignphphelper/SecSignHelper.php';
$request = OAuth2\Request::createFromGlobals();
$response = new OAuth2\Response();
$secsignid = new SecSignHelper;
// validate authorization request
if (!$server->validateAuthorizeRequest($request, $response)) {
    $response->send();
    die;
}
if (empty($_POST)) {
    echo'<html>
            <head>
                <meta charset="UTF-8">
                <script src="https://ajax.googleapis.com/ajax/libs/jquery/2.2.0/jquery.min.js"></script>
            </head>
            <body style="max-width: 350px; margin:10px auto;">
            <h1>PROVIDER</h1>
            <p>Mit der Anmeldung bestätigen Sie, dass "Consumer1" auf ihre Notizen zugreifen darf.</p>';
    //issue SecSign login form 
    echo $secsignid->buildLoginForm("SecSign OAuth2.0 Provider Login", $extPath, "true");
} else {
    $authenticated = $secsignid->validateLogin($_POST);
    if($authenticated === true){
        //For this simple example we assume that the user verifies his rights with the login
        $is_authorized = true;
        $userid = $result = '';
        $user_secsign_id = $_POST['secsigniduserid'];
        $db = new \PDO($database['dsn'], $database['username'], $database['password']);
        try {
            $stmt = $db->prepare('SELECT * FROM oauth_users WHERE secsignid=?');
            $stmt->execute(array($user_secsign_id));
            $result = $stmt->fetch(PDO::FETCH_OBJ);
        } catch(PDOException $ex) {
            echo "Database error";
        }
        if($result){
            $server->handleAuthorizeRequest($request, $response, $is_authorized, $result->user_id);
            $code = substr($response->getHttpHeader('Location'), strpos($response->getHttpHeader('Location'), 'code=')+5, 40);
        } else {
            echo "No SecSignID found!";
        }
    } else {
        //issue error message
        echo $authenticated;
    }
    $response->send();
}

Mit folgender URL wird das Formular zur Autorisierung angezeigt. Wenn sich ein Nutzer nun mit der SecSign ID Zwei-Faktor Authentifizierung anmeldet, bestätigt er (in diesem Beispiel automatisch), dass er seine Notiz für „consumer1“ freigeben möchte:

http://localhost:8088/authorize.php?response_type=code&client_id=consumer1&state=xyz

Der Authorisierungs-Code kann nun dafür genutzt werden, um den Access-Token anzufragen:

curl -u consumer1:c1pass http://localhost:8088/token.php -d 'grant_type=authorization_code&code=IHR_AUTORISIERUNGS_CODE'

Wenn alles klappt, erhalten sie den Access-Token, welcher dazu genutzt werden kann die eigentliche Resource (die Notiz) des Nutzers anzufragen:

curl localhost:8088/resource.php -d 'access_token=885afbadec8bac21c9867aabe3be1c044f52bbdb'

Die folgenden Hinweise geben einen Anhaltspunkt, wie Sie einen OAuth2 Client bzw. OAuth Consumer realisieren. Bisher haben wir den Provider manuell bedient, den gleichen Ablauf werden wir nun in einem simplen Beispiel-Consumer umsetzen. Um nur einen kurzen Überblick über die Funktionsweise des Consumers zu geben wurden Fehlerausgaben etc. weggelassen.

Der Consumer besteht besteht nur aus der index.php:

<?php
//Consumer login credentials for the provider
$consumerName = "consumer1";
$consumerPassword = "c1pass";
//Provider end points
$providerHost = "http://localhost:8088/";
$providerToken = $providerHost."token.php";
$providerResource = $providerHost."resource.php";
$providerAuthorize = $providerHost."authorize.php";
// Display all error messages
ini_set('display_errors',1);error_reporting(E_ALL);
session_start();
$session = sha1(session_id());
echo '
        <html>
        <head>
            <meta charset="UTF-8">
            <script src="https://ajax.googleapis.com/ajax/libs/jquery/2.2.0/jquery.min.js"></script>
        </head>
        <body style="max-width: 350px; margin:10px auto;">
        <h1>CONSUMER 1</h1>
        ';
if (isset($_GET) && array_key_exists("code", $_GET) && array_key_exists("state", $_GET)) {
  //The consumer may request the access token and the note if all GET parameter have been transmitted successfully 
  // The "state" parameter has to match the hashed session of the user (CSRF)
  if ($_GET['state'] !== $session) {
    echo "Your session has expired. Please try again.";
  } else {
    // Request access token 
    $post = array(
        'grant_type' => 'authorization_code',
        'code' => urlencode($_GET['code'])
    );
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, $providerToken);
    curl_setopt($ch, CURLOPT_TIMEOUT, 30);
    curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_BASIC);
    curl_setopt($ch, CURLOPT_USERPWD, "$consumerName:$consumerPassword");
    curl_setopt($ch, CURLOPT_POSTFIELDS, $post);
    $result = curl_exec($ch);
    curl_close($ch);
    $response = json_decode($result);
    $accessToken = $response->access_token;
    // Request note
    $post = array('access_token' => $accessToken);
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, $providerResource);
    curl_setopt($ch, CURLOPT_TIMEOUT, 30);
    curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt($ch, CURLOPT_POSTFIELDS, $post);
    $result = curl_exec($ch);
    curl_close($ch);
    $response = json_decode($result);
    $note = $response->note;
    echo "Your note: " . $note;
    // Note can now be saved in the DB
  }
} else {
  
  //Eelcome page if no or faulty GET parameter have been transmitted
    $output = '
        <p>Do you want to publish a note?</p>
        <ol>
            <li>
                <a href="#">Add new note</a>
            </li>
            <li><a href="' . $providerAuthorize . '?response_type=code&client_id=' . $consumerName . '&state=' . $session . '">
                    Use note from PROVIDER
                </a>
            </li>
        </ol>
       ';
    echo $output;
}
echo '</body></html>';

Wenn Sie nun im Browser http://localhost:8089 aufrufen erhalten Sie die Startseite des Consumers. Klicken Sie auf den Link, dass Sie eine Notiz übertragen möchten, werden Sie zum Provider weitergeleitet. Dort authentifizieren Sie sich mit Hilfe Ihrer SecSign ID und nehmen gleichzeitig die OAuth Autorisierung vor. War dies erfolgreich werden Sie zurück zum Consumer geleitet, welcher dann den Access Token anfragt. Wenn der Access Token vorliegt, kann die Notiz angefragt werden. Die Notiz kann dann weiter verarbeitet und gespeichert werden. Hier gibt der Consumer die Notiz einfach aus.
Keywords: 2 factor authentication OAuth, Two-factor authentication OAuth, 2fa OAuth, How to use OAuth, How to integrate OAuth, OAuth php

Wir haben eine stetig wachsende Liste an APIs und Plugins um die SecSign ID Zwei-Faktor Authentifizierung einfach und schnell in jedes Projekt zu integrieren.
Wir bieten nicht nur APIs in zahlreichen Programmiersprachen, sondern auch Plugins für CMS, Server und VPN Umgebungen, oAuth2 und zahlreiche mehr. Die Plugins nutzen unsere APIs und bieten zusätzliche Funktionen, zum Beispiel Nutzer Management, einfache und native Installation, Logging oder die Integration in Firewalls oder Active Directories.

Das JIRA Plugin beispielsweise nutzt die JAVA-API. Die PHP-API und JS-API wird von WordPress, Joomla, Drupal, Typo3 und vielen anderen genutzt. Die ASP.net/C#-API wird für die Windows und Cisco VPN genutzt und die C-API findet Verwendung um Unix SSH Services zu schützen. Die Objective-C API wird für unsere AppleTV und iPhone und iPad Apps genutzt.

Sie können die SecSign ID Zwei-Faktor Authentifizierung und den Zwei-Faktor Login durch eine einfach Integration des Plugins in Ihre Website oder Ihre Testumgebung kennenlernen. Oder testen Sie den Login auf unserer Website, ohne sich vorher zu registrieren. Sie haben bereits eine SecSign ID oder hätten gerne eine? Loggen Sie sich jetzt ein und nutzen Sie das Portal oder registrieren Sie sich ganz unkompliziert.

Erfahren Sie selbst, wie schnell und unkompliziert der Login Prozess mit der Challenge-Response Authentifizierung mit 2048-bit Schlüsselpaaren ist. Sie brauchen keine Passwörter, und es werden keine vertraulichen Logindaten übertragen. Einfache Integration und unkomplizierte Nutzung.

Für mehr Informationen zum patentierten SafeKey Verfahren finden Sie hier.

Falls Sie eine API für eine Programmiersprache vermissen kontaktieren Sie uns unverbindlich. Falls Sie Hilfe mit der Integration in ein existierendes System brauchen oder kein passendes Plugin für Ihr Content Management System finden, kontaktieren Sie unser Support Team und wir helfen Ihnen gerne weiter.