Konfigurasi Authentication

Ketika Auth::attempt dipanggil, Laravel harus tahu dari mana user dicari, tabel apa yang dipakai, dan strategi apa yang dipakai untuk mengingat status login. Semua jawaban itu berada di satu file: config/auth.php. File ini termasuk konfigurasi bawaan yang paling jarang perlu diubah, justru karena nilainya sudah masuk akal untuk sebagian besar aplikasi. Namun begitu kebutuhan tumbuh — dua jenis pengguna, reset password dengan masa berlaku khusus — file inilah tempat pertama yang harus kita kenali.

Anatomi config/auth.php #

Berikut isi asli config/auth.php pada aplikasi Laravel 13 segar, dipangkas dari blok komentarnya:

<?php

use App\Models\User;

return [
    'defaults' => [
        'guard' => env('AUTH_GUARD', 'web'),
        'passwords' => env('AUTH_PASSWORD_BROKER', 'users'),
    ],

    'guards' => [
        'web' => [
            'driver' => 'session',
            'provider' => 'users',
        ],
    ],

    'providers' => [
        'users' => [
            'driver' => 'eloquent',
            'model' => env('AUTH_MODEL', User::class),
        ],

        // 'users' => [
        //     'driver' => 'database',
        //     'table' => 'users',
        // ],
    ],
];

Tiga blok pertama file ini saling merujuk, jadi kita bedah satu per satu:

1. defaults — guard default bernama web dan password broker default bernama users. Setiap kali kita memanggil Auth::attempt() tanpa keterangan tambahan, guard inilah yang bekerja.
2. guards — mendaftarkan guard bernama web dengan driver session, memakai provider users. Driver session adalah satu-satunya driver yang didukung untuk guard berbasis state di Laravel 13.
3. providers — mendaftarkan sumber data user bernama users: driver eloquent dengan model App\Models\User. Ketika Auth::attempt mencari pemilik email yang diketik, query dijalankan lewat model inilah.

Provider alternatif yang dikomentari menunjukkan opsi kedua: driver database yang memakai query builder langsung ke tabel, tanpa model Eloquent. Perbandingannya:

Melihat Nilai Runtime dengan config:show #

Karena setiap nilai bisa digeser lewat environment variable seperti AUTH_GUARD, cara paling jujur memeriksa konfigurasi adalah bertanya pada aplikasi yang sedang berjalan. Artisan menyediakan perintah config:show untuk itu:

php artisan config:show auth

Output yang Dihasilkan:

  auth .......................................................................  
  defaults ⇁ guard ....................................................... web  
  defaults ⇁ passwords ................................................. users  
  guards ⇁ web ⇁ driver .............................................. session  
  guards ⇁ web ⇁ provider .............................................. users  
  guards ⇁ sanctum ⇁ driver .......................................... sanctum  
  guards ⇁ sanctum ⇁ provider ........................................... null  
  providers ⇁ users ⇁ driver ........................................ eloquent  
  providers ⇁ users ⇁ model .................................. App\Models\User  
  passwords ⇁ users ⇁ provider ......................................... users  
  passwords ⇁ users ⇁ table ............................ password_reset_tokens  
  passwords ⇁ users ⇁ expire .............................................. 60  
  passwords ⇁ users ⇁ throttle ............................................ 60  
  password_timeout ..................................................... 10800  

Output di atas memperlihatkan sesuatu yang menarik: guard sanctum ikut terdaftar meski tidak ada di file config/auth.php. Guard tersebut disuntikkan saat runtime oleh service provider milik package Laravel Sanctum — bukti bahwa config:show menampilkan konfigurasi gabungan hasil merge, bukan sekadar isi file.

Skenario Multi-Guard #

Satu guard web memang cukup untuk aplikasi dengan satu tabel pengguna. Skenario yang lazim membutuhkan lebih adalah aplikasi dengan dua populasi user terpisah, misalnya pelanggan dan admin internal yang datanya memang hidup di tabel berbeda. Kita mendaftarkan guard dan provider keduanya secara eksplisit:

'guards' => [
    'web' => [
        'driver' => 'session',
        'provider' => 'users',
    ],
    'admin' => [
        'driver' => 'session',
        'provider' => 'admins',
    ],
],

'providers' => [
    'users' => [
        'driver' => 'eloquent',
        'model' => App\Models\User::class,
    ],
    'admins' => [
        'driver' => 'eloquent',
        'model' => App\Models\Admin::class,
    ],
],

Dengan konfigurasi seperti itu, area admin menggunakan guard kedua secara eksplisit: Auth::guard('admin')->attempt($credentials) untuk login, Auth::guard('admin')->user() untuk membaca user yang sedang aktif, dan $request->user('admin') di controller. Guard default tetap web, sehingga kode yang tidak menyebut guard secara eksplisit tidak berubah perilakunya. Contoh di atas adalah display example — sandbox Course ini memakai satu guard, jadi kita tidak menjalankannya di sini.

Konfigurasi Reset Password #

Dua blok terakhir file mengurus pemulihan password. Blok passwords mendaftarkan broker bernama users — sekumpulan aturan yang dipakai Password facade saat mengirim tautan reset:

'passwords' => [
    'users' => [
        'provider' => 'users',
        'table' => env('AUTH_PASSWORD_RESET_TOKEN_TABLE', 'password_reset_tokens'),
        'expire' => 60,
        'throttle' => 60,
    ],
],

'password_timeout' => env('AUTH_PASSWORD_TIMEOUT', 10800),

Setiap kunci punya peran yang spesifik:

• provider — menunjuk provider users, agar reset password mencari user di sumber data yang sama dengan login.
• table — tabel password_reset_tokens sebagai tempat token reset disimpan.
• expire — token reset berlaku 60 menit sejak diterbitkan.
• throttle — user harus menunggu 60 detik sebelum boleh meminta token baru, mencegah permintaan massal.

Sedangkan password_timeout mengatur hal yang berbeda: masa berlaku konfirmasi password (dalam detik) untuk aksi sensitif seperti mengubah email — nilai 10800 berarti tiga jam, sama dengan bawaan framework. Alur reset passwordnya sendiri akan kita praktikkan di chapter khusus di section ini; yang penting sekarang adalah kita tahu seluruh angkanya hidup di file ini.

Konfigurasi yang sudah kita petakan ini bekerja diam-diam di latar: guard menyala, provider menunjuk ke model User. Tugas berikutnya adalah menghidupkan alur pertama yang benar-benar memakainya — menerima user baru ke dalam database. Kita bangun alur registrasi lengkap di chapter Registrasi Pengguna . Rujukan resminya ada di dokumentasi Authentication .