مقاله

کی session cookie و کی Bearer token؟ مقایسه امنیت، مقیاس و معماری برای monolith، SPA و API موبایل.

Session در مقابل Token — احراز هویت Laravel برای وب، SPA و موبایل

Session در مقابل Token — احراز هویت Laravel برای وب، SPA و موبایل

اشتباه رایج: استفاده از session برای اپ موبایل native یا token در Blade سنتی بدون درک CSRF. Laravel هر دو را پشتیبانی می‌کند — انتخاب به نوع کلاینت و deployment بستگی دارد.

Session-based (stateful)

کاربر login می‌کند → سرور session id در cookie encrypted می‌دهد → هر request cookie می‌فرستد → Laravel session را از Redis/file می‌خواند.

مناسب: Blade monolith، Breeze، admin panel سنتی.

مزیت: revoke فوری با logout، CSRF built-in، ساده.

معایب: کلاینت‌های غیرمرورگر مشکل‌دار؛ scale نیاز Redis مشترک.

Token-based (stateless نسبی)

Login → token (Sanctum) → کلاینت در هر request header می‌فرستد → سرور token را در DB/hash چک می‌کند.

مناسب: اپ موبایل، API عمومی، microservice consumer.

مزیت: cross-platform، بدون cookie.

معایب: مدیریت expire/revoke، ذخیره امن token در کلاینت.

جدول مقایسه

معیارSessionToken (Sanctum)
کلاینتمرورگرموبایل، API، SPA جدا
CSRFلازممعمولاً نه (Bearer)
Logoutinvalidate sessiondelete token
Scale افقیRedis sessionDB tokens + cache

SPA میانه — Sanctum Stateful

Vue/React روی subdomain همان سایت: Sanctum cookie + CSRF مثل monolith — بهترین DX. راهنمای Sanctum.

JWT چطور؟

Laravel رسماً Sanctum را پیشنهاد می‌دهد؛ JWT با tymon/jwt-auth گزینه است اما خودتان revoke و refresh را مدیریت کنید.

تنظیم session در .env

SESSION_DRIVER=redis
SESSION_DOMAIN=.example.com
SANCTUM_STATEFUL_DOMAINS=app.example.com

راهنمای env.

دو مدل همزمان

رایج: وب admin با session، API موبایل با Sanctum — هر دو روی یک User model.

جمع‌بندی

مرورگر same-site → session. موبایل/third-party → token. Authorization جدا از authentication است.

معماری auth