It uses Laravel Sanctum with token-based authentication for the API. When a request comes in, the Sanctum middleware uses the token to resolve the model, but it returns an App model instead of the User model. This even works without the App model implementing the Authenticatable interface, and auth()->user() returns an instance of the App model.

I’m using a custom model (e.g., an App model) for authentication with Laravel Sanctum. Do I need to make this model implement the Authenticatable interface? If so, it seems to imply that the model uses passwords and the rememberToken field, even though Sanctum does not require them. This also feels like a violation of the Interface Segregation Principle.

In practice, implementing only the methods Sanctum actually needs (such as getAuthIdentifier()) works. However, my tests fail because Sanctum::actingAs() requires an instance of Authenticatable, meaning I would need to write custom authentication logic in my tests, which adds unnecessary overhead and database interaction.

Is there a better way to authenticate a user without relying on passwords, or am I forced to implement an interface that my model doesn’t fully use?

practical example from yesterday using Livewire and FluxUi

database has three 'boolean' fields. In the UI, I have three checkboxes wire modelled to the database record. The checkboxes are NOT set by 1 in the eloquent model.

Add boolean cast in the Model and the model data is now true/false not 1/0 and checkboxes now reflect the state of the Model.

Sort of. Values true and false convert to 1 and 0 when cast to int, so that would work without casting — if your DBMS stores booleans as integers.

It's still good practice to use the boolean cast when you're representing boolean values. It also ensures the property is serialized as a boolean field in JSON if it's sent to the front end, or as an API response.

Right, that makes sense, but now I’m trying to understand the purpose of the boolean cast then. If I assign a real boolean (true/false), PHP or the database already handles converting it to 1 or 0 when saving. So what does the boolean cast actually do in practice?

Is it mainly just for reading converting the database integer back into a PHP boolean rather than affecting how data is written? Because if it doesn’t normalize string truthy values like 'on', 'yes', 'true', etc., then the cast seems useful only when retrieving data, not when setting it.

The boolean cast is for using boolean values on the model. That means means the property returns a boolean value, and you can set a boolean value on it, even though it may be stored in an integer column in the database. It doesn't automatically convert any truthy or falsy value to boolean.

(string) "on" will not be casted to (bool) true or database-friendly (int) 1 unless you have your own custom cast class doing so.

String values "on", "yes", "true" are treated as boolean true only in request: https://laravel.com/docs/12.x/requests#retrieving-boolean-input-values

Also be aware that simple boolean casting (bool) "on" will lead you to wrong behavior as any non-empty string (including "off" and "false") is casted to boolean true:

(bool) "on"    === true
(bool) "yes"   === true
(bool) "true"  === true

(bool) "off"   === true
(bool) "no"    === true
(bool) "false" === true

I’ve hit a confusing behavior with Laravel’s native boolean cast. Here’s a minimal example:

$user = User::first();
$user->test = 'on';
$user->save();

Model:

protected function casts(): array
{
    return [
        'test' => 'boolean',
    ];
}

When saving, I get:

SQLSTATE[HY000]: General error: 1366 Incorrect integer value: 'on' for column 'test'

Is this expected behavior — that the boolean cast only applies to actual booleans or numbers, not strings? Shouldn’t $model->test = 'on' go through casting before hitting the database?