Auth

devdojo/auth is a self-contained authentication layer for any Laravel application. Instead of scaffolding controllers into your app, it ships the entire flow — login, registration, verification, password reset and confirmation, social sign-in, and TOTP two-factor — as Folio pages powered by Volt, backed by config you can edit by hand or through a visual /auth/setup designer.

It is the base of the Foundation stack: accounts, billing, and teams all depend on it.

This page is a condensed overview. The full package documentation lives in the sections alongside this page — start with Getting Started, pick an install guide for your starter kit, or browse the Authentication Pages.

#Requirements

• PHP 7.4+ (tested through 8.4) and Laravel 8 – 13 — the widest support matrix in the Foundation family.
• Laravel Socialite, Livewire 3/4, Volt, Folio, Google2FA, and BaconQrCode are pulled in automatically by Composer.
• The package ships a Pest feature suite and Dusk browser tests, and publishes a CI workflow (auth:ci) you can drop into your own repo.

#Installation

Require the package and publish its assets, config, CI workflow, and migrations:

composer require devdojo/auth

php artisan vendor:publish --tag=auth:assets
php artisan vendor:publish --tag=auth:config
php artisan vendor:publish --tag=auth:ci
php artisan vendor:publish --tag=auth:migrations
php artisan migrate

Then extend the package's base user model so your App\Models\User picks up the auth columns and behavior:

use Devdojo\Auth\Models\User as AuthUser;

class User extends AuthUser
{
    // ...
}

The service provider (Devdojo\Auth\AuthServiceProvider) is auto-discovered, binds a shared PragmaRX\Google2FA\Google2FA instance, and forces livewire.inject_assets to true so the auth pages render correctly even when Livewire auto-injection is disabled.

#Routes and pages

Once installed, these authentication routes are ready to use. The user-facing pages are Folio pages under the package's resources/views/pages/auth directory; the package also registers convenience redirects and a few controller routes.

The logout, verify-email, and password-confirm routes sit behind the auth/web middleware; social routes are web only; email verification adds signed and throttle:6,1.

#Configuration

Publishing auth:config writes five files under config/devdojo/auth/, merged into these config namespaces:

#Settings

config/devdojo/auth/settings.php is where most behavior lives. Highlights:

return [
    'redirect_after_auth' => '/',
    'redirect_after_logout' => '/',
    'registration_enabled' => true,
    'registration_include_name_field' => false,
    'registration_require_email_verification' => false,
    'password_min_length' => 8,
    'password_require_uppercase' => false,
    'password_require_numeric' => false,
    'password_require_special_character' => false,
    'password_require_uncompromised' => false,
    'enable_2fa' => false,
    'login_show_social_providers' => true,
    'social_providers_location' => 'bottom',
    'check_account_exists_before_login' => false,
    'include_wire_navigate' => true,
];

The password flags feed the Devdojo\Auth\Rules\PasswordStrength rule that validates registration and resets. enable_2fa is the global switch for two-factor (see below). registration_enabled and enable_email_registration gate the sign-up path.

#redirect_after_auth

This is the single most important setting to get right. Every successful authentication outcome routes through config('devdojo.auth.settings.redirect_after_auth'):

• Login and registration redirect()->intended(...) there.
• The two-factor challenge lands there once passed.
• Email verification redirects there with ?verified=1.
• The social callback sends verified social sign-ins there.
• Password confirmation returns the user to their intended URL, falling back to it.

Its sibling redirect_after_logout is used by LogoutController (falling back to /). Because these are config-driven, changing where users land after auth is a one-line edit — no controller overrides.

#Social providers

config/devdojo/auth/providers.php ships definitions for Facebook, Twitter/X, Google, GitHub, GitLab, Bitbucket, LinkedIn, Slack, Apple, Microsoft, Pinterest, Reddit, TikTok, and Twitch. Each entry carries a name, an inline brand svg, scopes/parameters, a stateless flag, an active flag (all default to false), a socialite flag, and client_id/client_secret pulled from environment variables:

'github' => [
    'name' => 'Github',
    'active' => false,
    'socialite' => true,
    'client_id' => env('GITHUB_CLIENT_ID'),
    'client_secret' => env('GITHUB_CLIENT_SECRET'),
    // 'svg' => '...',
],

To enable a provider, set its credentials in .env and flip active to true — or do both from the /auth/setup/providers screen without touching files. Providers marked socialite: true (Facebook, Twitter/X, LinkedIn, Google, GitHub, GitLab, Bitbucket, Slack) work out of the box with the bundled Laravel Socialite; the rest (Apple, Microsoft, Pinterest, Reddit, TikTok, Twitch) need the matching community driver from Socialite Providers. The SocialController handles the redirect/callback handshake; the sign-in is then persisted via the social-provider models.

To let a User model query and manage its linked identities, add the HasSocialProviders trait:

use Devdojo\Auth\Traits\HasSocialProviders;

class User extends Devdojo\Auth\Models\User
{
    use HasSocialProviders;
}

It provides socialProviders(), linked_social_providers, hasSocialProvider($slug), getSocialProviderUser($slug), and addOrUpdateSocialProviderUser($slug, $data).

#The visual setup designer

/auth/setup is a live editor for the appearance and behavior config, rendered as Folio/Volt pages (setup/appearance, setup/settings, setup/language, setup/providers). It uses a set of Livewire components (Logo, Background, Color, Alignment, Favicon, Css) to preview changes and write them back into the published config files, so restyling your login screen doesn't require a deploy.

Access is guarded by the view-auth-setup middleware group (ViewAuthSetup):

if (app()->isLocal() || Gate::allows('viewAuthSetup')) {
    return $next($request);
}

abort(403);

The appearance.php config it edits controls the logo (SVG string or image), background (color or image with overlay), color (text, button, input), alignment, and favicon — everything the login screen renders.

#Two-factor authentication

2FA is off by default. Set devdojo.auth.settings.enable_2fa to true to turn it on globally. When enabled (and Fortify is present), the provider registers Fortify's two-factor feature with confirmation and password confirmation required. The package supplies:

• A setup page at /user/two-factor-authentication.
• A challenge page at /auth/two-factor-challenge, enforced by the two-factor-challenged and two-factor-enabled middleware groups.
• Action classes under Devdojo\Auth\Actions\TwoFactorAuth — GenerateQrCodeAndSecretKey, GenerateNewRecoveryCodes, and DisableTwoFactorAuthentication.
• Events TwoFactorAuthenticationEvent and TwoFactorAuthenticationDisabled.

QR codes are produced with bacon/bacon-qr-code and codes verified through the shared Google2FA singleton. The accounts package reuses these exact columns, encryption format, and recovery codes for its Security tab, so a 2FA secret set up in the account area satisfies the auth challenge at login.

#Extension points

• Rebrand without code via /auth/setup or by editing config/devdojo/auth/appearance.php.
• Change post-auth destinations with redirect_after_auth / redirect_after_logout.
• Tune the password policy with the password_* settings, which drive the PasswordStrength rule.
• Add social sign-in by activating providers in providers.php and adding the HasSocialProviders trait.
• Override the pages — publish the views (auth:components exposes the element components) and customize the Blade/Volt markup.
• Localize everything through config/devdojo/auth/language.php.

Pair auth with accounts to give users a full self-service account area — profile, connected accounts, 2FA, sessions, and billing — on top of the identity this package establishes.