Laravel Sanctum vs Passport en 2026 : Authentification API et Questions d'Entretien
Comparaison technique de Laravel Sanctum et Passport pour l'authentification API en 2026. Guide pratique avec exemples de code et questions d'entretien technique.

Laravel Sanctum et Passport offrent deux approches distinctes pour l'authentification des API, et choisir le mauvais package conduit soit à une complexité inutile, soit à des failles de sécurité. Ce guide détaille les deux solutions avec des exemples de code pratiques et des questions d'entretien réelles.
Sanctum gère l'authentification des SPA et les tokens API simples. Passport implémente OAuth2 complet avec codes d'autorisation, credentials client et tokens de rafraîchissement. La plupart des applications nécessitent Sanctum.
Laravel Sanctum vs Passport : Différences Fondamentales
Sanctum fournit une authentification légère par tokens conçue pour les applications first-party. Le package utilise l'authentification basée sur les cookies de session pour les SPA et les tokens d'accès personnels pour les applications mobiles et les API simples.
Passport implémente la spécification OAuth2 complète, incluant les serveurs d'autorisation, les grants de credentials client et l'authentification machine-to-machine. Cette complexité se justifie pour les applications nécessitant d'autoriser l'accès à des tiers.
| Fonctionnalité | Sanctum | Passport | |----------------|---------|----------| | Cas d'usage principal | SPAs, Apps Mobiles, APIs Simples | OAuth2 Tiers, Machine-to-Machine | | Type de Token | Tokens hachés simples | JWT avec scopes OAuth2 | | Auth Session | Oui (basé cookies) | Non | | Grants OAuth2 | Aucun | Spécification complète | | Taille du Package | Minimal | Conséquent | | Configuration | Simple | Complexe |
Implémenter Sanctum pour l'Authentification SPA
L'authentification SPA de Sanctum repose sur les cookies de session Laravel plutôt que sur les tokens API. Le frontend et le backend doivent partager le même domaine de premier niveau pour que cela fonctionne.
return [
'stateful' => explode(',', env('SANCTUM_STATEFUL_DOMAINS', sprintf(
'%s%s',
'localhost,localhost:3000,127.0.0.1,127.0.0.1:8000,::1',
env('APP_URL') ? ','.parse_url(env('APP_URL'), PHP_URL_HOST) : ''
))),
'expiration' => null, // Tokens never expire by default
'middleware' => [
'verify_csrf_token' => App\Http\Middleware\VerifyCsrfToken::class,
'encrypt_cookies' => App\Http\Middleware\EncryptCookies::class,
],
];Le SPA doit appeler l'endpoint du cookie CSRF avant d'effectuer des requêtes authentifiées. Cela établit la session et définit le cookie XSRF-TOKEN.
// Frontend: Initialize CSRF protection before login
async function initializeAuth() {
await fetch('/sanctum/csrf-cookie', {
credentials: 'include'
});
}
async function login(email, password) {
await initializeAuth();
const response = await fetch('/api/login', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'X-XSRF-TOKEN': getCookie('XSRF-TOKEN'),
'Accept': 'application/json'
},
credentials: 'include',
body: JSON.stringify({ email, password })
});
return response.json();
}Authentification par Token API avec Sanctum
Les applications mobiles et les intégrations tierces utilisent des tokens d'accès personnels au lieu des cookies de session. Sanctum stocke ces tokens sous forme de hachages SHA-256 dans la base de données.
namespace App\Http\Controllers;
use App\Models\User;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Hash;
use Illuminate\Validation\ValidationException;
class AuthController extends Controller
{
public function createToken(Request $request)
{
$request->validate([
'email' => 'required|email',
'password' => 'required',
'device_name' => 'required',
]);
$user = User::where('email', $request->email)->first();
if (! $user || ! Hash::check($request->password, $user->password)) {
throw ValidationException::withMessages([
'email' => ['The provided credentials are incorrect.'],
]);
}
// Token with abilities (scopes)
$token = $user->createToken(
$request->device_name,
['read', 'write'] // Optional abilities
);
return response()->json([
'token' => $token->plainTextToken,
'expires_at' => null // Configure in sanctum.php
]);
}
public function revokeToken(Request $request)
{
// Revoke current token
$request->user()->currentAccessToken()->delete();
return response()->json(['message' => 'Token revoked']);
}
}La protection des routes s'effectue avec le middleware auth:sanctum. La vérification des abilities du token utilise la méthode tokenCan.
use Illuminate\Support\Facades\Route;
Route::middleware('auth:sanctum')->group(function () {
Route::get('/user', function (Request $request) {
return $request->user();
});
Route::post('/posts', function (Request $request) {
// Check if token has write ability
if (! $request->user()->tokenCan('write')) {
abort(403, 'Token does not have write permissions');
}
// Create post logic
});
});Prêt à réussir tes entretiens Laravel ?
Entraîne-toi avec nos simulateurs interactifs, fiches express et tests techniques.
Quand Utiliser Laravel Passport
Passport devient nécessaire lorsque l'application agit comme serveur d'autorisation OAuth2. Les scénarios courants incluent :
- Des développeurs tiers construisant des intégrations avec l'API
- L'authentification machine-to-machine entre microservices
- Des applications nécessitant la conformité OAuth2 pour des clients entreprise
- Des systèmes nécessitant la rotation des tokens de rafraîchissement et la validation JWT
namespace App\Http\Controllers\Api;
use App\Models\User;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Hash;
class PassportController extends Controller
{
public function issueToken(Request $request)
{
$request->validate([
'email' => 'required|email',
'password' => 'required',
]);
$user = User::where('email', $request->email)->first();
if (! $user || ! Hash::check($request->password, $user->password)) {
return response()->json([
'error' => 'invalid_credentials'
], 401);
}
// Create OAuth2 token with scopes
$token = $user->createToken('API Token', ['read-posts', 'write-posts']);
return response()->json([
'access_token' => $token->accessToken,
'token_type' => 'Bearer',
'expires_at' => $token->token->expires_at
]);
}
}Passport supporte également le grant client credentials pour l'authentification serveur-à-serveur sans contexte utilisateur.
// Machine-to-machine authentication
// config/auth.php
'guards' => [
'api' => [
'driver' => 'passport',
'provider' => 'users',
],
],
// routes/api.php - Client credentials protected route
Route::middleware('client')->group(function () {
Route::get('/machine-data', function () {
return response()->json(['data' => 'Machine accessible']);
});
});Bonnes Pratiques de Sécurité pour l'Authentification API Laravel
Les deux packages nécessitent des mesures de sécurité additionnelles au-delà de la configuration de base. L'expiration des tokens, le rate limiting et la validation appropriée des scopes préviennent les vulnérabilités courantes.
namespace App\Providers;
use Illuminate\Support\ServiceProvider;
use Laravel\Sanctum\Sanctum;
use Laravel\Sanctum\PersonalAccessToken;
class AuthServiceProvider extends ServiceProvider
{
public function boot(): void
{
// Set token expiration (Sanctum)
Sanctum::authenticateAccessTokensUsing(function ($token, $isValid) {
// Expire tokens after 24 hours
$expiration = config('sanctum.expiration');
if ($expiration === null) {
return $isValid;
}
return $isValid && $token->created_at->gt(now()->subMinutes($expiration));
});
}
}L'implémentation du rate limiting sur les endpoints d'authentification prévient les attaques par force brute. Laravel 12 fournit une configuration flexible du rate limiter via la facade RateLimiting.
use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Support\Facades\RateLimiting;
public function boot(): void
{
RateLimiting::for('login', function ($request) {
return Limit::perMinute(5)->by($request->ip());
});
RateLimiting::for('api', function ($request) {
return Limit::perMinute(60)->by($request->user()?->id ?: $request->ip());
});
}Questions d'Entretien sur l'Authentification Laravel
Les entretiens techniques testent fréquemment la compréhension des patterns d'authentification API. Ces questions apparaissent dans les entretiens de développeurs Laravel à tous les niveaux.
Q: Quelle est la différence entre l'authentification SPA et l'authentification par token de Sanctum ?
L'authentification SPA utilise les cookies de session Laravel avec protection CSRF. Le frontend appelle /sanctum/csrf-cookie pour établir une session, puis les requêtes suivantes incluent automatiquement le cookie de session. L'authentification par token utilise des tokens Bearer dans l'en-tête Authorization, adaptée aux applications mobiles et aux intégrations tierces où les cookies sont impraticables.
Q: Quand choisir Passport plutôt que Sanctum ?
Passport implémente OAuth2 complet, requis lorsque des développeurs tiers ont besoin de s'intégrer à l'API via le flow authorization code, ou lorsque l'authentification machine-to-machine nécessite des grants client credentials. Sanctum gère les applications first-party plus simplement.
Q: Comment Sanctum stocke-t-il les tokens API ?
Sanctum stocke le hash SHA-256 de chaque token dans la table personal_access_tokens. Le token en texte clair n'est retourné qu'une seule fois lors de la création. Cette approche signifie que des données de base de données compromises ne peuvent pas révéler de tokens valides.
Q: Comment implémenter les abilities/scopes de token dans Sanctum ?
// Creating token with abilities
$token = $user->createToken('api-token', ['posts:read', 'posts:write']);
// Checking abilities in controller
if ($request->user()->tokenCan('posts:write')) {
// Authorized for write operations
}
// Middleware-based ability check
Route::middleware(['auth:sanctum', 'ability:posts:write'])
->post('/posts', [PostController::class, 'store']);Q: Comment révoquer tous les tokens d'un utilisateur dans Sanctum ?
// Revoke all tokens
$user->tokens()->delete();
// Revoke specific token by ID
$user->tokens()->where('id', $tokenId)->delete();
// Revoke current token only
$request->user()->currentAccessToken()->delete();Migration de Passport vers Sanctum
Les applications ayant commencé avec Passport mais n'utilisant que l'authentification par token simple peuvent migrer vers Sanctum pour réduire la complexité. La migration nécessite la mise à jour de la création de tokens, la configuration du middleware et toutes les vérifications de scopes.
// Migration helper: Convert Passport tokens to Sanctum
use App\Models\User;
use Laravel\Passport\Token;
// This is a one-way migration - run once then remove Passport
User::chunk(100, function ($users) {
foreach ($users as $user) {
$passportTokens = Token::where('user_id', $user->id)
->where('revoked', false)
->get();
foreach ($passportTokens as $token) {
$user->createToken(
$token->name ?? 'migrated-token',
$token->scopes ?? []
);
}
}
});La mise à jour du middleware des routes de auth:api vers auth:sanctum et le remplacement de $request->user()->token()->scopes par $request->user()->currentAccessToken()->abilities sont nécessaires.
Conclusion
- Sanctum convient aux SPAs, applications mobiles et APIs first-party avec une configuration minimale
- Passport gère les serveurs d'autorisation OAuth2 et les intégrations tierces
- L'authentification SPA utilise les cookies de session ; l'authentification API utilise les tokens Bearer
- Les abilities de token fournissent un contrôle de permissions granulaire dans Sanctum
- Le rate limiting et l'expiration des tokens sont des mesures de sécurité essentielles quel que soit le package choisi
- La plupart des applications Laravel devraient commencer avec Sanctum et n'ajouter Passport que lorsque la conformité OAuth2 devient une exigence
Passe à la pratique !
Teste tes connaissances avec nos simulateurs d'entretien et tests techniques.
Partager
Articles similaires

Laravel Livewire 3 en 2026 : Applications Réactives et Questions d'Entretien
Maîtrisez Laravel Livewire 3 avec ce guide complet sur les composants réactifs, l'intégration Alpine.js, la validation en temps réel et les questions d'entretien technique.

Tests Laravel en 2026 : Pest, Mocking et Questions d'Entretien Technique
Guide complet des tests Laravel avec Pest en 2026 : tests unitaires, tests fonctionnels, mocking de facades, tests d'architecture, mutation testing et questions d'entretien technique pour developpeurs PHP.

Laravel 12 en 2026 : nouvelles fonctionnalités, Starter Kits et questions d'entretien
Découvrez les nouveautés de Laravel 12 en 2026 : Starter Kits redessinés avec React 19 et WorkOS AuthKit, guide de migration depuis Laravel 11, et questions d'entretien technique essentielles.