Authentication

Authentication ships as laraspring/auth, a Composer package your application installs. It owns the behaviour of signing up, signing in and proving who you are; your edition owns every screen those flows put in front of a user.

That split is the thing to understand before you extend any of it.

What you get out of the box

Feature	Flag	Default
Registration	LARASPRING_AUTH_REGISTRATION	on
Login, logout, sessions	—	always on
Password reset	—	always on
Email verification	—	always on
Password confirmation	—	always on
Magic links	LARASPRING_AUTH_MAGIC_LINKS	on
Social sign-in	LARASPRING_AUTH_SOCIAL	off
Two-factor (TOTP)	LARASPRING_AUTH_TWO_FACTOR	on

Feature flags remove routes, they do not hide links

Turning a feature off does not render a disabled button. The routes are never registered at all: the endpoint 404s, and Route::has('register') is false. Your frontend asks the same question through Ziggy and hides the link:

{route().has('register') && <TextLink href={route('register')}>Sign up</TextLink>}

One consequence worth planning around: a flag is read while the application boots and the route table is built. Changing it at runtime does nothing, and a test that flips one has to rebuild the application around it.

Configuration

Publish the config to change anything:

php artisan vendor:publish --tag=laraspring-auth-config

Every value has an environment variable behind it, so most installations never publish at all:

LARASPRING_AUTH_REGISTRATION=false
LARASPRING_AUTH_MAGIC_LINKS=true
LARASPRING_AUTH_MAGIC_LINK_EXPIRES=15
LARASPRING_AUTH_SOCIAL=github,google
LARASPRING_AUTH_TWO_FACTOR=true
LARASPRING_AUTH_TWO_FACTOR_WINDOW=1

Where the flows send a user is configuration too, not a hardcoded route:

'redirects' => [
    'home' => 'dashboard',   // route name, where a signed-in user lands
    'logout' => '/',         // a path, because a guest has to be able to reach it
],

Screens are named, not rendered

The package never calls Inertia::render(). It asks for a screen by name and lets your edition decide what that name draws:

// inside the package
return $this->screens->render(Screens::LOGIN, ['canResetPassword' => true]);

// App\Auth\InertiaAuthScreenRenderer, in your edition
public function render(string $screen, array $props = []): Responsable
{
    return Inertia::render(self::PAGES[$screen] ?? 'auth/'.$screen, $props);
}

The names the package will ask for are constants on Laraspring\Auth\Support\Screens: login, register, forgot-password, reset-password, verify-email, confirm-password, magic-link, two-factor-challenge and two-factor-settings.

This is where you point a flow at your own page. Want a bespoke login screen? Change what login maps to. You never fork the package to change a screen, and a Livewire or Blade edition supplies its own renderer with the package untouched.

Route names are public API

Your frontend resolves routes by name through Ziggy, so login, password.request, magic-link.verify, oauth.callback and two-factor.* are part of the contract. Renaming one breaks every edition at once. If you need a route gone, turn its flag off rather than renaming or deleting it.

The user model

The package never names your user class. It walks the default guard to its provider to the model, so renaming App\Models\User, moving it, or pointing the guard at something else needs no change in the package and no configuration from you.

Everything it needs from that model is what a Laravel skeleton already gives you: name, email, password, email_verified_at and remember_token.

Tables

The package ships and runs its own migrations. social_accounts holds linked external identities, two_factor_credentials holds enrolled second factors. It never adds columns to your users table, so uninstalling is a matter of dropping two tables of its own.

If you would rather own the schema:

php artisan vendor:publish --tag=laraspring-auth-migrations

Publishing restamps the timestamps so the copies sort after your own migrations. Set laraspring-auth.migrations to false afterwards, or the tables are created twice.

Taking over the routes entirely

php artisan vendor:publish --tag=laraspring-auth-routes

That writes the package's route file to routes/laraspring-auth.php as a starting point. Set laraspring-auth.routes.enabled to false and register it yourself. Keep the names.