Laravel + Flutter : Arrêtez de galérer avec les Cookies, passez aux API Tokens !

Sommaire

• Pourquoi choisir les API Tokens avec Laravel Sanctum pour votre architecture ?

  • La fin des cauchemars sur mobile (Flutter)

  • Une universalité à toute épreuve

• Comment protéger vos API Tokens avec Laravel Sanctum côté Frontend ?

  • Maîtriser le localStorage sous Vue.js et Pinia

  • Le coffre-fort de Flutter

• Le match décisif : Cookies SPA vs API Tokens avec Laravel Sanctum

• Guide express : Déployer vos API Tokens avec Laravel Sanctum (Laravel 12)

• FAQ : L'essentiel sur les API Tokens avec Laravel Sanctum

Avez-vous déjà voulu jeter votre ordinateur par la fenêtre après des heures à déboguer des cookies de session sur une application mobile ? Rassurez-vous, vous n'êtes pas le seul ! Oubliez la gestion fastidieuse des cookies SPA (Stateful) : si vous construisez une architecture couplant Laravel 12 en backend, Vue 3 (avec Pinia) pour le web et Flutter pour le mobile, le choix de l'authentification est vital. C'est ici qu'interviennent les API Tokens avec Laravel Sanctum.

Les jetons personnels (Bearer Tokens) vont littéralement vous sauver la mise. Prêts à simplifier votre code et à accélérer vos développements ? C'est parti !

Pourquoi choisir les API Tokens avec Laravel Sanctum pour votre architecture ?

La fin des cauchemars sur mobile (Flutter)

Les cookies, c'est comme essayer de faire rentrer un carré dans un rond quand on passe sur un environnement mobile. L'approche "Tokens" gagne haut la main ici ! Flutter gère de façon native, et de manière enfantine, les en-têtes Authorization: Bearer. C'est le standard absolu de l'industrie mobile.

Une universalité à toute épreuve

Imaginez un pass VIP unique qui ouvre toutes les portes de votre club. Avec un jeton, c'est exactement la même sensation : vous utilisez la même logique pour votre site Vue.js et votre application Flutter.

• Un seul middleware (auth:sanctum) à gérer côté Laravel.

• Une seule méthode d'authentification à maintenir.

• Zéro prise de tête avec les domaines : Si votre API est sur api.domaine.com et votre frontend sur app.domaine.com, vous n'aurez aucun souci de politique SameSite ou de partage complexe de cookies.

Comment protéger vos API Tokens avec Laravel Sanctum côté Frontend ?

Le principal argument souvent brandi par les détracteurs des jetons est la vulnérabilité au XSS (où un script malveillant volerait votre token dans le navigateur). C'est un défi réel, mais tout à fait maîtrisable.

Maîtriser le localStorage sous Vue.js et Pinia

Ne laissez pas les clés sous le paillasson ! Voici comment sécuriser intelligemment votre frontend Vue 3 :

• Pinia pour l'état : Stockez le token directement dans votre store Pinia. L'accès en mémoire est ultra-rapide.

• La Persistance : Utilisez le module pinia-plugin-persistedstate. Il gardera votre token bien au chaud même si l'utilisateur rafraîchit la page.

• La technique du Sanitize : Laravel 12 vous protège déjà massivement contre les injections en backend. Côté client, veillez simplement à toujours échapper vos données (ce que Vue.js fait merveilleusement bien par défaut avec les moustaches {{ }}).

Le coffre-fort de Flutter

Sur votre smartphone, le problème XSS n'existe pas de la même manière que sur un navigateur web. Le remède est simple et redoutablement efficace : utilisez le package flutter_secure_storage. Il va stocker le token de manière totalement chiffrée dans le trousseau de clés (Keychain/Keystore) de l'appareil. Fort Knox dans votre poche !

Le match décisif : Cookies SPA vs API Tokens avec Laravel Sanctum

Un petit tableau vaut souvent mieux qu'un long discours. Voici pourquoi le jeton est votre meilleur allié :

php artisan install:api

Note : Cette commande configure automatiquement les routes, le middleware auth:sanctum et publie la configuration.

Étape 2 : Préparation du Modèle
Assurez-vous que votre modèle User utilise le trait qui permet la génération des jetons :

use Laravel\Sanctum\HasApiTokens;

class User extends Model {
    use HasApiTokens;
    // ...
}

Étape 3 : Le Contrôleur (Qualité Production)
Oubliez les contrôleurs bâclés. Voici un exemple de méthode login qui respecte les normes les plus strictes : typage fort (strict_types), injection de dépendances (Form Requests), et rejet explicite des sessions :

<?php

declare(strict_types=1);

namespace App\Http\Controllers\Api;

use App\Http\Controllers\Controller;
use App\Http\Requests\Auth\LoginRequest;
use App\Models\User;
use Illuminate\Http\JsonResponse;
use Illuminate\Support\Facades\Hash;
use Illuminate\Validation\ValidationException;

class AuthController extends Controller
{
    /**
     * Authentifie l'utilisateur et génère un jeton d'accès API.
     */
    public function login(LoginRequest $request): JsonResponse
    {
        // 1. La validation est déléguée proprement au Form Request
        $credentials = $request->validated();

        // 2. Requête en base de manière explicite
        $user = User::where('email', $credentials['email'])->first();

        // 3. Vérification du mot de passe (On évite Auth::attempt pour rester 100% stateless)
        if (! $user || ! Hash::check($credentials['password'], $user->password)) {
            throw ValidationException::withMessages([
                'email' => ['Les identifiants fournis sont incorrects.'],
            ]);
        }

        // 4. Génération du Bearer Token
        $token = $user->createToken('auth_token')->plainTextToken;

        return response()->json([
            'token' => $token,
        ]);
    }
}

Pourquoi ce code est un modèle du genre ?

• declare(strict_types=1) : Force PHP à lever des erreurs fatales si les types ne correspondent pas, évitant les bugs silencieux.

• Pas de Auth::attempt() : Auth::attempt() a pour effet de bord de démarrer une session Laravel (ce qu'on veut absolument éviter en API pure). Utiliser Hash::check garde le processus strictement stateless.

• ValidationException : Renvoie automatiquement un code HTTP 422 avec le format JSON standard de Laravel, parfait pour être intercepté par Axios ou Dio côté frontend.

Étape 4 : L'interception côté Clients
Il ne vous reste plus qu'à configurer vos clients (Vue.js via Axios ou Flutter via Dio) pour qu'ils interceptent chaque requête sortante et y injectent systématiquement l'en-tête :
Authorization: Bearer {votre_token}

FAQ : L'essentiel sur les API Tokens avec Laravel Sanctum

Q : Les tokens Sanctum ont-ils une durée de vie illimitée ? R : Par défaut, oui. Mais vous pouvez très facilement configurer une durée d'expiration en modifiant le fichier config/sanctum.php. C'est une excellente pratique de sécurité !

Q : Que faire si le téléphone d'un utilisateur est volé ? R : Pas de panique ! Laravel vous permet de révoquer un jeton spécifique (ou tous les jetons d'un utilisateur) en une seule ligne de code grâce à $user->tokens()->delete();.

Q : Est-ce vraiment si catastrophique d'utiliser les cookies sur mobile ? R : "Catastrophique", non, mais cela vous oblige à créer des intercepteurs complexes pour synchroniser manuellement les sessions, ce qui alourdit considérablement votre code Flutter. Le Token est fait pour ça, utilisez-le !

En centralisant votre logique d'authentification autour des API Tokens avec Laravel Sanctum, vous gagnez un temps précieux, vous unifiez votre code et vous vous épargnez de belles migraines architecturales. Votre écosystème Laravel + Vue + Flutter est maintenant prêt à affronter n'importe quel défi en toute sécurité !