Extract auth concerns from Model into an Authable base class

[xentixar]

Problem

Auth-specific behavior currently sits on the generic Model class (e.g. getAuthKeyName()). Model should stay generic. Only models that authenticate need auth methods and attributes.

The Auth facade also documents User, which is not a framework type. Auth already resolves the model configured per actor in config/auth.php, so locking the type to User is wrong.

Proposal

1. Add an Authable base class that extends Model and owns everything auth needs.
2. Remove auth methods from Model (starting with getAuthKeyName()).
3. Put auth-related helpers on Authable instead of reading raw attributes through Auth, including things like:
   • auth key name (getAuthKeyName())
   • auth identifier / primary key
   • password hash access
   • remember token get/set
   • two-factor secret / recovery codes access
   • persist (save()) where Auth needs it
4. Type Auth (Auth facade + Authenticate) against Authable, not User or an untyped $user.
5. Application auth models (User, later Admin, etc.) extend Authable instead of Model directly.

Multi-actor auth via config/auth.php stays the same. Each actor still points at its own model. Those models just extend Authable.

Example

// before
class User extends Model { ... }

// after
class User extends Authable { ... }

[techmahedy]

@xentixar I’ll check it, but did you also review runtime/config/auth.php? We can support multi-actor authentication by configuring the actors in this file.

I agree this is still an issue with the facade annotation:

@method static login(User $user, bool $remember = false): void

[xentixar]

@xentixar I’ll check it, but did you also review runtime/config/auth.php? We can support multi-actor authentication by configuring the actors in this file.

I agree this is still an issue with the facade annotation:

@method static login(User $user, bool $remember = false): void

@techmahedy Multi-actor via config/auth.php is fine, this isn't about changing that. Just the facade/login typing: there's no User in the framework, so an Authenticatable contract fits better for whatever model the actor uses.

[techmahedy]

Ok i am going to use newly created Authable contract