Tak Berkategori June 5, 2026 7 min read

Authentication di Laravel — Breeze, Fortify, dan Alur Lengkapnya

enricoriskip

Software Engineer

← All articles

Kalau kamu baru mulai belajar authentication di Laravel, kamu pasti pernah bingung melihat daftar namanya: Breeze, Jetstream, Fortify, Sanctum, Passport. Semuanya berkaitan dengan auth, tapi tidak jelas mana yang harus dipakai dan apa bedanya.

Sebelum masuk ke kode, kita perlu ngerti dulu siapa yang melakukan apa — karena di sinilah kebingungan itu biasanya berasal.

🗺️ Peta Ekosistem Auth Laravel

Bayangkan auth di Laravel seperti restoran. Ada tiga lapisan yang berbeda tugasnya:

Breeze / Jetstream
  ↓
"Ruang makan + dekorasi" — UI yang dilihat user (form login, register, halaman profil)

Fortify
  ↓
"Dapur" — engine auth yang memproses semua logika (validasi, login, reset password)

Sanctum / Passport
  ↓
"Sistem kasir khusus" — manajemen token untuk API dan SPA

Breeze adalah starter kit yang paling simpel — dia install Fortify di balik layar dan sekaligus menyediakan halaman-halaman Blade (atau Inertia/Vue) yang sudah jadi.

Fortify adalah headless authentication — dia hanya menyediakan logika dan route, tanpa UI sama sekali. Cocok kalau kamu mau bikin tampilan sendiri atau butuh auth untuk SPA.

Sanctum dipakai untuk menerbitkan token API — baik personal access token untuk mobile app maupun cookie-based auth untuk SPA.

🔑 Bagian 1 — Alur Authentication Breeze (Web / Session)

Install

composer require laravel/breeze --dev
php artisan breeze:install blade   # versi Blade biasa
# atau
php artisan breeze:install vue     # versi Inertia + Vue

npm install && npm run dev
php artisan migrate

Setelah ini, Laravel menyediakan route, controller, dan view untuk: register, login, logout, forgot password, reset password, dan verifikasi email.

Alur Register

Ini yang terjadi ketika pengguna baru mengisi form registrasi:

1. User isi form → POST /register

2. RegisteredUserController@store dipanggil

3. Validasi input (nama, email, password)
   └── Email harus unik, password minimal 8 karakter

4. User::create([...]) — password otomatis di-hash lewat bcrypt

5. Auth::login($user) — user langsung di-login setelah register

6. Session dibuat, session ID disimpan di cookie browser

7. Redirect ke /dashboard

Di balik layar, proses ini ditangani Fortify — Breeze hanya menyediakan tampilan form-nya.

Alur Login

1. User isi email + password → POST /login

2. Fortify::authenticateUsing dipanggil
   └── Default: cek email + password dengan Auth::attempt()

3. Auth::attempt(['email' => ..., 'password' => ...])
   └── Ambil user dari database berdasarkan email
   └── Verifikasi password dengan Hash::check()

4. Kalau cocok → Auth::login($user)
   └── Session dibuat
   └── Session ID dikirim ke browser via cookie

5. Redirect ke /dashboard (atau intended URL)
   Kalau gagal → redirect balik ke form login dengan error

Session — Apa yang Sebenarnya Terjadi

Ini bagian yang sering tidak dipahami secara utuh.

Browser                          Server (Laravel)
  │                                    │
  │  POST /login (email + password)    │
  │ ─────────────────────────────────► │
  │                                    │  Validasi credentials
  │                                    │  Buat session
  │                                    │  Simpan user_id di session storage
  │                                    │
  │  Set-Cookie: laravel_session=xyz   │
  │ ◄───────────────────────────────── │
  │                                    │
  │  GET /dashboard                    │
  │  Cookie: laravel_session=xyz       │
  │ ─────────────────────────────────► │
  │                                    │  Baca cookie → cari session
  │                                    │  Session ada → ambil user_id
  │                                    │  Auth::user() tersedia
  │                                    │
  │  Response: halaman dashboard       │
  │ ◄───────────────────────────────── │

Yang disimpan di cookie browser bukan data user — hanya ID session. Data aslinya (termasuk user_id) tersimpan di server (file, database, atau Redis tergantung konfigurasi SESSION_DRIVER).

Middleware `auth` — Penjaga Route

Setelah user login, route yang butuh autentikasi dilindungi dengan middleware auth:

// routes/web.php
Route::middleware('auth')->group(function () {
    Route::get('/dashboard', DashboardController::class);
    Route::resource('/posts', PostController::class);
});

Yang terjadi ketika request masuk ke route ini:

Request → Middleware auth dipanggil
             │
             ├── Auth::check() → apakah session punya user yang valid?
             │
             ├── Ya → lanjutkan ke controller
             │
             └── Tidak → redirect ke /login

Mengakses user yang sedang login di controller:

// Cara 1 — lewat facade
$user = Auth::user();
$id   = Auth::id();

// Cara 2 — lewat request (lebih disukai di controller)
$user = $request->user();

// Cara 3 — helper global
$user = auth()->user();

Alur Logout

// AuthenticatedSessionController@destroy

public function destroy(Request $request): RedirectResponse
{
    Auth::guard('web')->logout();

    // Hapus data session saat ini
    $request->session()->invalidate();

    // Regenerate CSRF token untuk keamanan
    $request->session()->regenerateToken();

    return redirect('/');
}

Kustomisasi Logika Login

Fortify memungkinkan kamu mengganti logika autentikasi sepenuhnya lewat Fortify::authenticateUsing():

// app/Providers/FortifyServiceProvider.php

use Laravel\Fortify\Fortify;
use Illuminate\Support\Facades\Hash;

public function boot(): void
{
    // Ganti logika default dengan logika kustom
    Fortify::authenticateUsing(function (Request $request) {
        $user = User::where('email', $request->email)->first();

        if ($user && Hash::check($request->password, $user->password)) {
            // Tambahkan kondisi ekstra — misalnya cek status akun
            if (! $user->is_active) {
                return null; // tolak login
            }

            return $user;
        }

        return null; // credentials salah
    });
}

📡 Bagian 2 — Authentication untuk API (Token-based)

Untuk API yang dikonsumsi mobile app atau SPA, session tidak relevan — karena HTTP stateless dan client tidak bisa menyimpan cookie dengan cara yang sama.

Solusinya adalah token: server menerbitkan token saat login, client menyimpannya, dan menyertakannya di setiap request berikutnya di header Authorization.

Install Sanctum

composer require laravel/sanctum
php artisan vendor:publish --provider="Laravel\Sanctum\SanctumServiceProvider"
php artisan migrate

Tambahkan trait HasApiTokens ke model User:

use Laravel\Sanctum\HasApiTokens;

class User extends Authenticatable
{
    use HasApiTokens, HasFactory, Notifiable;
}

Alur Login API

// routes/api.php
Route::post('/login', [AuthController::class, 'login']);
Route::middleware('auth:sanctum')->group(function () {
    Route::get('/me', [AuthController::class, 'me']);
    Route::post('/logout', [AuthController::class, 'logout']);
});

// app/Http/Controllers/AuthController.php

class AuthController extends Controller
{
    public function login(Request $request)
    {
        $request->validate([
            'email'    => 'required|email',
            'password' => 'required',
        ]);

        // Cek credentials
        if (! Auth::attempt($request->only('email', 'password'))) {
            return response()->json([
                'message' => 'Email atau password salah'
            ], 401);
        }

        $user  = Auth::user();

        // Buat token — beri nama sesuai device/keperluan
        $token = $user->createToken('mobile-app')->plainTextToken;

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

    public function me(Request $request)
    {
        // Auth::user() tersedia karena middleware auth:sanctum
        return response()->json($request->user());
    }

    public function logout(Request $request)
    {
        // Hapus hanya token yang sedang dipakai
        $request->user()->currentAccessToken()->delete();

        return response()->json(['message' => 'Logged out']);
    }
}

Alur Request API dengan Token

Mobile App                       Laravel API
    │                                 │
    │  POST /api/login                │
    │  {email, password}              │
    │ ──────────────────────────────► │
    │                                 │  Validasi → buat token
    │  {token: "1|abc123..."}         │
    │ ◄────────────────────────────── │
    │                                 │
    │  Simpan token di storage lokal  │
    │                                 │
    │  GET /api/me                    │
    │  Authorization: Bearer 1|abc123 │
    │ ──────────────────────────────► │
    │                                 │  Middleware auth:sanctum
    │                                 │  Cari token di tabel personal_access_tokens
    │                                 │  Token valid → ambil user
    │                                 │
    │  {id: 1, name: "Budi", ...}     │
    │ ◄────────────────────────────── │

🔄 Bagian 3 — Session Auth vs Token Auth

Ini perbandingan yang perlu dipahami sebelum memilih pendekatan:

Session Auth (Breeze / web)          Token Auth (Sanctum / API)
────────────────────────────         ──────────────────────────
State tersimpan di server            Stateless — server tidak
(file / database / redis)            simpan state apapun

Identifikasi via cookie              Identifikasi via header
laravel_session=xyz                  Authorization: Bearer xyz

CSRF protection dibutuhkan           CSRF tidak relevan
(karena cookie otomatis terkirim)    (token harus eksplisit dikirim)

Cocok untuk:                         Cocok untuk:
  - Web app tradisional              - REST API
  - Server-side rendered (Blade)     - Mobile app
  - SPA same-domain                  - SPA cross-domain

🗺️ Gambaran Besar — Semua Komponen dan Posisinya

Permintaan login dari user
         │
         ▼
┌─────────────────────────────────┐
│         routes/web.php          │
│   POST /login                   │
│   Middleware: guest             │ ← hanya boleh diakses kalau belum login
└──────────────┬──────────────────┘
               │
               ▼
┌─────────────────────────────────┐
│  Fortify (engine di balik layar)│
│  authenticateUsing()            │
│   → Auth::attempt()             │
│   → Hash::check()               │
└──────────────┬──────────────────┘
               │
       ┌───────┴───────┐
       │ Berhasil       │ Gagal
       ▼               ▼
Auth::login()    redirect + error
Session dibuat
       │
       ▼
┌─────────────────────────────────┐
│  Route berikutnya               │
│  Middleware: auth               │ ← cek session / token
│  Auth::user() tersedia          │
│  Controller berjalan            │
└─────────────────────────────────┘

📊 Perbandingan Breeze vs Fortify vs Sanctum

	Breeze	Fortify	Sanctum
Menyediakan UI	✅ Blade / Inertia	❌	❌
Logika auth	Lewat Fortify	✅ Langsung	—
Untuk web (session)	✅	✅	✅ (SPA)
Untuk API (token)	❌	❌	✅
Install otomatis	✅	Manual	Manual
Cocok untuk	Starter cepat	Kustomisasi penuh	API / Mobile / SPA

💡 Ingat!

Dua hal yang paling sering bikin bingung di auth Laravel:

Pertama — Breeze bukan pengganti Fortify. Breeze menggunakan Fortify. Kalau kamu install Breeze, Fortify sudah ada di dalamnya. Kalau kamu mau kustomisasi logika login, kamu edit di Fortify — bukan di Breeze.

Kedua — middleware auth dan auth:sanctum itu berbeda. auth (tanpa guard) menggunakan session — cocok untuk route web. auth:sanctum membaca token dari header Authorization — cocok untuk route API. Salah pilih guard, request yang valid pun bisa ditolak.

Dan satu kebiasaan yang sangat direkomendasikan: selalu pisahkan route web di routes/web.php dan route API di routes/api.php. Keduanya punya middleware group yang berbeda — web group punya session dan CSRF, api group tidak.

Share Twitter/X LinkedIn