DevDojo Auth: a plug and play authentication package for Laravel

Authentication you add to an app that already exists

DevDojo Auth is a plug'n play authentication package for any Laravel application, and it is distributed on Packagist as `devdojo/auth`. The documentation lives at devdojo.com/auth/docs, and the package is MIT licensed.

The positioning is the interesting part. The package can be installed into any new Laravel application, or into any of the available Laravel Starter Kits. A starter kit scaffolds a whole application, with its own views, routes, tests and Tailwind configuration, and is what you reach for when you are starting a project. A package like this one is what you reach for when the project exists and the authentication part is missing or is a mess.

The mechanism is conventional Laravel package plumbing. The package ships configuration, migrations, routes, Blade views and front-end assets, and an installation step publishes the parts that have to be copied into the host application rather than staying inside the vendor directory. The user's model then extends the package's model, which is how the package's authentication behaviour reaches your application code without you copying it.

The repository layout supports that reading. There are `config/`, `database/`, `resources/`, `routes/`, `src/`, `tests/` and `public/` directories, plus `composer.json`, `phpstan.neon` and `phpunit.xml.dist` for static analysis and the test configuration. The front-end is built with Vite and Tailwind, with `vite.config.js` and `postcss.config.js` at the root and a `package.json` that carries Tailwind 4, Vite 7, axios, and a couple of smaller packages.

The topics list the scope: auth, authentication, laravel, login, register, users. There is nothing here about roles, permissions or teams, and that is the point of the package's narrowness.

Four publish tags and a model to extend

The installation is a composer require followed by a publishing step and a migration.

composer require devdojo/auth

The package has to publish its assets, configs and more into the application, and it does that with four separate artisan tags:

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

The tags are worth reading one by one, because each one copies a different kind of artefact and a project that publishes only some of them will get a half-installed package. Assets are the compiled front-end, config is the package configuration, migrations are the database changes, and `auth:ci` is the continuous integration environment file, which is why the repository root carries a `.env.dusk.ci`.

Then the migrations run:

php artisan migrate

and finally the application's user model is extended rather than replaced:

use Devdojo\Auth\Models\User as AuthUser;

class User extends AuthUser

The instruction is to make that change in your `App\Models\User` model. The alternative, editing the package's model in the vendor directory, is the classic way to lose your changes on the next `composer update`, and the extension approach is the reason the package can ship new behaviour in a patch release.

The README then lists the routes you get: login at `/auth/login`, register at `/auth/register`, forgot password, password reset at `/auth/password/reset`, a password reset token route, password confirmation at `/auth/password/confirm`, and a two-factor challenge at `/auth/two-factor-challenge`. There is also a two-factor setup page at `/user/two-factor-authentication`, and a logout route at `/auth/logout`.

Social providers arrive as a trait

The optional part of the package is social login, and it is delivered as a trait rather than as a configuration entry. The README calls it the HasSocialProviders trait, and adding it to the user model brings in the social authentication helpers:

<?php

namespace App\Models;

use Devdojo\Auth\Traits\HasSocialProviders; // Import the trait

class User extends Devdojo\Auth\Models\User
{
    use HasSocialProviders; // Use the trait in the User model

    // Existing User model code...
}

The shape of that snippet is the point. The trait is imported with a `use` statement at the top of the file and then pulled into the class body, and the model still extends the package's user model, so the trait adds to the package behaviour rather than replacing it.

The split between the required part and the optional part is worth noting. The authentication routes and the two-factor pages come with the package itself, and the social providers are something a team opts into by editing one file. For an application that only needs email and password, nothing has to be configured, and for one that needs a social login, the change is a single trait on a model that already exists.

What the package does not do is decide which providers you get. The trait is named for the social providers in the plural, but the documentation excerpt in the repository does not enumerate them, and the provider list, the credentials and the callback routes are the sort of thing that belongs to the configuration you publish. Anyone adopting this should read the provider section of the documentation rather than assume a set of providers.

The test suite only runs inside a host application

The testing section is the most unusual part of the documentation, and it is worth reading carefully before contributing.

The tests in this package are designed to run from inside a consuming Laravel application, not from the package folder. The setup described in CONTRIBUTING.md is to require the package via a path repository and then replace the application's `tests/` directory with a symlink to the package's `tests/` folder. From the app root you run the Feature suite with `./vendor/bin/pest` and the Browser suite with Laravel Dusk.

Running `./vendor/bin/pest` standalone from the package root is expected to fail, with:

Pest\Exceptions\TestCaseClassOrTraitNotFound
The class `DuskTestCase` was not found.

The README is explicit that this is by design and not a broken install, and then gives the three reasons. The test classes live in the `Tests\` namespace and rely on the host application's `Tests\` to `tests/` autoload mapping, while the package's own composer autoload maps `Devdojo\Auth\Tests\` to `tests/`, so `Tests\DuskTestCase` and `Tests\TestCase` never resolve standalone. The `Tests\TestCase` class extends the framework's application test case, which boots the host application's `bootstrap/app.php`, and there is no bootable application inside the package. And the `tests/Browser` suite is Laravel Dusk, which needs a real running application plus ChromeDriver.

This is a defensible design for a package whose tests need a real application, and it also means the package cannot be verified by a clone-and-run. Anyone evaluating it has to build a host application before the test suite says anything, and that is the main friction in the adoption path.

Issues are closed and support moved elsewhere

The About section carries an unusual piece of policy. The maintainers have closed issues for this repository and recommend that anyone who wants to report an issue or make a suggestion does so at devdojo.com/questions. Pull requests, however, are described as open to any kind.

That is a significant operational fact for anyone evaluating the project, and it is not a criticism so much as a fact to plan around. An issue tracker is where most adopters look for evidence of how a project handles real problems, and this one is closed by policy. The replacement is a support channel on the vendor's own site, which means the conversation happens away from the repository and away from the version history.

The practical consequences are that a bug report and its resolution are not visible in the Git history, that the repository's issue count is not a signal of anything, and that a team that wants a public, versioned record of problems has to look elsewhere. It also means the pull request path carries more weight than usual, since that is the part of the contribution flow that stays in the open.

The release history is brisk. Three versions were published on the same day, 2026-01-26: v2.1.0, v2.1.1 and v2.2.0, which suggests a coordinated release across a family of related packages. The repository is not archived and the last push was on 2026-07-25, and the changelog is in `CHANGELOG.md` in the repository. The licence is MIT, so the package carries no obligations beyond attribution for anyone shipping it inside an application.

Editorial conclusion

DevDojo Auth suits a team with an existing Laravel application that needs working authentication screens and two-factor support without rebuilding the app around a starter kit, and that is comfortable publishing Blade views and Tailwind assets into its own tree. It does not suit a project that expects to file issues in the repository, because the maintainers have closed issues and moved support to devdojo.com/questions, and it does not suit a contributor who wants to run the test suite from the package alone, since that is expected to fail by design. Before adopting, read the documentation at devdojo.com/auth/docs, plan the publishing step for the assets and config, and extend the package user model in your application rather than editing the package.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. thedevdojo/auth on GitHub