Voraussetzungen:
– Standard Laravel Authentifizierung (php artisan make auth)
– Laravel 5.3
– PHP >= 5.6

In diesem Beispiel werden alle Links welche im Projekt angelegt werden (Model Link::Class) mittels einer API ausgegeben.
Der User authentifiziert sich mithilfe eines api_token, welcher in der Datenbanktabelle users gespeichert wird.

Laravel bietet durch middleware ein mächtiges Werkzeug um sich an viele Stellen der Seite einzuhängen.
Um nun eine simple API Schnittstelle mit Authentifizierung via Api Token zu erstellen, genügen einige wenige Handgriffe.

Erstellen einer neuen Migration mithilfe des Werkzeugs artisan im Terminal:
php artisan make:migration add_api_token_to_users_table --table=users

Eine neue Migration wurde unter /database/migrations erstellt. Die Datei nun wie folgt anpassen:

string('api_token', 60)->default(null)->unique();
});
}

/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::table('users', function (Blueprint $table) {
$table->dropColumn(['api_token']);
});
}
}

Nachdem die Migration angepasst wurde führen wir sie im Terminal aus:
php artisan migrate
Migrated: 2016_12_08_145817_add_api_token_to_users_table

Wir haben nun in unserer Datenbanktabelle users eine neue Spalte angelegt.

Laravel 5.3 trennt die Routes in die Dateien web.php und api.php auf. Der RouteServiceProvider regelt die Gruppierung, Präfixe und auch die zu verwendende(n) Middleware.
Ich habe nun eine leere api.php angelegt und die Route::resource() Funktion verwendet. Diese regelt entsprechend der RESTful API Konventionen die Zugriffe.
Beispielhaft sehen solche Routings wie folgt aus:

+-----------+---------------------------+---------+------------------+
| Verb | Path | Action | Route Name |
+-----------+---------------------------+---------+------------------+
| GET | /resource | index | resource.index |
| GET | /resource/create | create | resource.create |
| POST | /resource | store | resource.store |
| GET | /resource/{resource} | show | resource.show |
| GET | /resource/{resource}/edit | edit | resource.edit |
| PUT/PATCH | /resource/{resource} | update | resource.update |
| DELETE | /resource/{resource} | destroy | resource.destroy |
+-----------+---------------------------+---------+------------------+

Mein Laravel Projekt enthält eine Klasse ApiController, welche von jeder Klasse im Ordner /app/Http/Controllers/Api/* verwendet wird.
Diese Regelt JSON Responses, Antwortcodes und Fehlerhandling.

Der Inhalt der api.php wird nun entsprechend ergänzt:
/routes/api.php

Route::group(['prefix' => 'v1'], function() {
Route::resource('links', 'Api\LinksController');
});

Die API ist in diesem Fall unter /api/v1/ erreichbar. Das Präfix api wird im Service Provider hinzugefügt, das Präfix v1 kommt in der api.php noch hinzu unter ‚prefix‘ = ‚v1‘.

Hierbei ist es sinnvoll, einem User bei seiner Registrierung einen zufälligen API Key zu generieren.
Dies machen wir indem /app/Http/Auth/RegisterController.php entsprechend angepasst wird.

protected function create(array $data)
{
return User::create([
'name' => $data['name'],
'email' => $data['email'],
'password' => bcrypt($data['password']),
'api_token' => str_random(60) // API TOKEN
]);
}

Ab jetzt wird der User bei seiner Registrierung einen neuen, zufälligen api_token erhalten.

Ein Token in der Users Table ist nun schon sehr hilfreich, jedoch brauchen wir nun eine Middleware, die entsprechend weiß wonach sie suchen soll.
Das bedeutet, dass im Falle eines API Tokens (get oder post) im Request ein User gesucht werden soll.

/app/Http/Middleware/AuthByToken.php
api_token)) {
Auth::loginUsingId(User::where('api_token', $request->api_token)->first()->id);
} else {
return Redirect::to('/');
// oder einen Fehler ausgeben
}

return $next($request);
}
}

Hier wird auf einen api_token im Request geprüft. Falls es einen api_token im Request gibt, wird er ausgelesen und ein User wird entsprechend gesucht.
Der erste User der gefunden wurde, wird ausgegeben und an die Methode Auth::loginUsingId(int $userid) übergeben.

Damit nun das Routing auch weiß, dass es eine Middleware gibt, welche bei API Aufrufen einen User nach api_token suchen soll, geben wir dem RouteServiceProvider.php entsprechend die Info über die neue Middleware mit:

/app/Providers/RouteServiceProvider.php
protected function mapApiRoutes()
{
Route::group([
'middleware' => 'api',
'middleware' => 'token', // API TOKEN
'namespace' => $this->namespace,
'prefix' => 'api',
], function ($router) {
require base_path('routes/api.php');
});
}

Wie man sieht wird die Middleware api aufgerufen und die middleware token. Man kann grundsätzlich mehrere Middleware mitgeben.

Noch findet Laravel die neue Middleware „token“ nicht. Damit sie gefunden wird, muss dem Kernel entsprechend gesagt werden, wo er sie finden kann:
/app/Http/Kernel.php
protected $routeMiddleware = [
'auth' => \Illuminate\Auth\Middleware\Authenticate::class,
'auth.basic' => \Illuminate\Auth\Middleware\AuthenticateWithBasicAuth::class,
'bindings' => \Illuminate\Routing\Middleware\SubstituteBindings::class,
'can' => \Illuminate\Auth\Middleware\Authorize::class,
'guest' => \App\Http\Middleware\RedirectIfAuthenticated::class,
'throttle' => \Illuminate\Routing\Middleware\ThrottleRequests::class,
'token' => \App\Http\Middleware\AuthByToken::class, // API TOKEN
];

Von nun an wird ein User nach seinem API Token gesucht, sobald ein API Aufruf erfolgt.
Das genaue Fehlerhandling, was bei nicht vorhandensein eines Tokens getriggert wird, kann in /app/Http/Middleware/AuthByToken.php geändert werden.
Es empfiehlt sich, da die API ggf. JSON zurückgibt, eine JSON Statusmeldung zurückzugeben:

/app/Http/Middleware/AuthByToken.php
api_token)) {
Auth::loginUsingId(User::where('api_token', $request->api_token)->first()->id);
} else {
return Response::json(['error' => [
'message' => "API Token not found...",
'status_code' => 403
]], 403);
}

return $next($request);
}
}