Starter kits, Fortify and social login

Pathshala’s team wants a React dashboard and a “Sign in with GitHub” button, and nobody wants to hand-build registration, password reset and sessions first. A starter kit scaffolds all of that in a minute. The catch is that the code lands in your own repository, so you own and maintain it, and one careless line in social sign-in can join a stranger to a parent’s account.

This lesson picks a kit and names what it generates, switches Fortify’s features on and off, adds social sign-in that refuses an unverified email (with a test that proves the refusal), and weighs WorkOS AuthKit and team support against the built-in path. The authentication the kit sets up is taken apart by hand in the next three lessons.

A starter kit is scaffolding that lives in your app

A starter kitstarter kit: Scaffolding that laravel new copies into your project: ready-made authentication controllers, pages, routes and config that then become your own code to maintain. is not a dependency you install and forget. laravel new --react (or --vue, --svelte, --livewire) copies controllers, pages, routes and config straight into your project. From then on the auth screens are your code, in your version control, changed like anything else you wrote. The React, Vue and Svelte kits render through InertiaInertia: A library that lets a server-side app such as Laravel keep its routes and controllers while React, Vue or Svelte draws each page; every response names a page component and the props it gets. More in “Single-page apps with Inertia 3”; the Livewire kit renders on the server with LivewireLivewire builds interactive interfaces from Blade components whose state lives on the server. and needs no JavaScript framework.

What arrives differs a little by kit, but each one brings the same backend. The React kit’s composer.json, for instance, pulls in Inertia, Fortify and a route helper:

{
    "require": {
        "php": "^8.3",
        "inertiajs/inertia-laravel": "^3.0",
        "laravel/fortify": "^1.37.2",
        "laravel/framework": "^13.17",
        "laravel/wayfinder": "^0.1.14"
    }
}

Because the files are yours, an upgrade to the framework does not rewrite them; you change them yourself. That is the trade for having every screen open to editing. Breeze and Jetstream, the older scaffolds, stopped receiving updates when these kits arrived with Laravel 12, so a new project starts from a kit.

Fortify does the authentication; the kit draws the pages

Underneath every kit sits Laravel Fortify, a headless authentication backend. Headless means it registers the routes and logic for registration, login, password reset, email verification, password confirmation and two-factor authentication, but renders no pages of its own. The starter kit supplies the pages; Fortify does the work behind them. Follow a single sign-in through it:

Each feature is one line in config/fortify.php. Comment the line out and Fortify stops registering its routes, which is how you ship a product without public registration, or without password reset. In the React, Vue and Svelte kits, also delete the pages’ references to those routes: Wayfinder generates route definitions at build time, so a reference to a missing route fails the build. What a new user looks like is yours too: Fortify calls the action class you bind, so a centre_id, a role or a welcome email is added there rather than in framework code.

<?php

// config/fortify.php (the relevant part). Each entry here switches one feature on.
// Comment a line out and Fortify stops registering that feature's routes.
return [

    // ... driver, guard, middleware and prefix settings above ...

    'features' => [
        Features::registration(),
        Features::resetPasswords(),
        Features::emailVerification(),
        Features::updateProfileInformation(),
        Features::updatePasswords(),
        Features::twoFactorAuthentication([
            'confirm' => true,       // make the user type a code before it is switched on
            'confirmPassword' => true,
        ]),
    ],

];

// What a user looks like when they register is yours to decide. Fortify calls the
// class you bind, so you add a centre_id, a role or a welcome email here:
//
//   app/Actions/Fortify/CreateNewUser.php
//   public function create(array $input): User
//   {
//       Validator::make($input, [...])->validate();
//       return User::create([... your columns ...]);
//   }

Social sign-in links an account only when the email is proven

Socialite handles sign-in through an OAuthOAuth: An authorization protocol that lets a user agree to sign in at a provider (such as Google or GitHub), which then tells your app who they are without sharing their password. provider such as GitHub or Google: the visitor signs in at the provider, and Socialite hands your app a user object with an id, a name and an email. The hard part is not the redirect. It is deciding which Pathshala account that provider user belongs to, a step called account linkingaccount linking: Deciding which existing user a third-party (social) sign-in belongs to, and attaching the provider identity to that account only when it is safe to do so..

The rule that keeps it safe is one question: did the provider confirm the email it sent you? An email address on its own proves nothing, because anyone can type someone else’s address when they register at a provider. So the action links a social sign-in to an existing account, or creates a new one, only when the provider marks that email verified (providers that speak OpenID Connect send this as the standard email_verified claim); otherwise it refuses.

The decision is a small action with three questions, and a feature test drives it with a fake provider user so it runs with no network and no browser. A verified email signs in a new visitor or links to the existing user who owns it; an unverified one is refused in both cases:

from session import run

# The four cases a safe account-linking action must get right: a new visitor and an
# existing user whose email the provider verified, and the refusal of both when it did not.
run(
    """
php artisan test --filter=LinkSocialAccountTest
""",
    app=True,
    overlay=("link-probe",),
)

$ php artisan test --filter=LinkSocialAccountTest
   PASS  Tests\Feature\LinkSocialAccountTest
  ✓ a new visitor with a verified email gets an account                  …s
  ✓ a verified email links to the existing account                       …s
  ✓ an unverified email is refused and nothing is linked                 …s
  ✓ an unverified email from a new visitor creates nothing               …s

  Tests:    4 passed (10 assertions)
  Duration: …s

All four pass. Now the tempting shortcut: match on email and link, whatever the provider says. Run the same safety check against that version:

from session import run

# The same safety check, run against the naive action. It is meant to fail: the
# naive action linked an unverified email to an existing account.
run(
    """
!php artisan test --filter=NaiveLinkTest
""",
    app=True,
    overlay=("link-probe",),
)

$ php artisan test --filter=NaiveLinkTest
   FAIL  Tests\Feature\NaiveLinkTest
  ⨯ an unverified email is refused and nothing is linked                 …s
  ────────────────────────────────────────────────────────────────────────────
   FAILED  Tests\Feature\NaiveLinkTest > an unverified email is refused and…
  Failed asserting that 1 is identical to 0.

  at tests/Feature/NaiveLinkTest.php:30
     26▕
     27▕         (new NaiveLinkSocialAccount)->resolve($incoming);
     28▕
     29▕         // We want nothing linked to Asha's account from an unverified email.
  ➜  30▕         $this->assertSame(0, SocialAccount::count());
     31▕     }
     32▕ }
     33▕

  1   tests/Feature/NaiveLinkTest.php:30


  Tests:    1 failed (1 assertions)
  Duration: …s
[exit status 1]

It fails on Failed asserting that 1 is identical to 0: the naive action linked a social account to Asha’s record from an email the provider never verified. In a real product, the attacker who did that would then sign in as Asha. The failing check is the proof that the verified-email guard is doing something; the passing check next to it is the proof the fix works.

When WorkOS AuthKit or team support is worth turning on

Two options sit beside the built-in path. WorkOS AuthKit is a hosted login. Each kit has a WorkOS variant that hands sign-in to WorkOS, which brings social providers, passkeys, email-based Magic Auth and enterprise single sign-on; switch its email-and-password method off and your app never handles a password. Team support (added with the installer’s --teams option) gives every user a personal team and a current team, puts the team in the URL as /{current_team}/dashboard, and reserves names such as settings, login and dashboard so a team slug cannot collide with a route.

Neither is without cost, so choose by the product rather than the fashion. The question that decides WorkOS is usually whether your customers are companies that must sign in with their own identity provider:

Practise

Work on your own Pathshala project, or the fake provider user from the example:

1. Install a kit into a throwaway project with laravel new --livewire, and list which files under app/ and resources/ it added. Decide which three you would most likely edit.
2. In config/fortify.php, comment out Features::registration() and confirm with php artisan route:list that the registration route is gone. Put it back.
3. Add a second case to LinkSocialAccountTest: a returning social account (a social_accounts row already exists) signs in as its own user even if a different email is now reported. Make it pass.

Then work through the self-check.

Interview questions

Warm-up: a starter kit is a dependency you can upgrade with Composer, true or false?

False, and the difference matters. A starter kit is scaffolding: laravel new --react copies controllers, pages, routes and config into your project, where they become your code under your version control. A framework upgrade does not rewrite those files, and there is no “kit version” to bump; you maintain the generated code yourself, which is the price of being able to edit every screen. What the kit installs as real Composer dependencies is the backend it leans on, such as Fortify and Inertia, and those you do upgrade. So treat the generated code as yours and the packages behind it as dependencies.

Key takeaways

• A starter kit copies auth controllers, pages and config into your app, so the generated code is yours to maintain, while the backend packages behind it stay Composer dependencies.
• Fortify is the headless authentication backend; each feature is a switch in config/fortify.php, and what registration creates is the action class you bind.
• Social sign-in is safe only when an existing account is linked after the provider has verified the email; an email match alone is an account-takeover path, and a test that fails on the weak version proves the guard works.
• WorkOS AuthKit is worth it when customers need enterprise single sign-on; team support is worth it when customers share data in groups, and both cost more than the built-in path.