Auth Laravel Package

Product Decisions This Supports

• Build vs. buy on identity: Authentication is a solved problem for the vast majority of Laravel products. Treating illuminate/auth as the default baseline removes an entire workstream (login, registration, password reset, email verification, session handling, password hashing) from the roadmap and concentrates engineering capacity on differentiators.
• MVP and time-to-market scoping: Supports committing to an aggressive launch date for user-facing products, because the auth foundation ships with the framework rather than needing to be designed, built, and security-reviewed. This is the single fastest path to a working "user signs up and logs in" slice in a Laravel codebase.
• Security and compliance risk posture: A community-audited, MIT-licensed core component of the most widely adopted PHP framework is a defensible answer to "how do we know our auth is safe?" It shifts risk from internal code review of bespoke crypto and session logic onto a maintained upstream with predictable release cadence.
• Buy-vs-extend sequencing for the auth roadmap: The package is the substrate, not the whole product. It lets you defer decisions on API tokens (Sanctum/Passport), OAuth/social login (Socialite), customized UI and flows (Fortify), and MFA until a customer actually demands them — each of those extends the same guards, providers, and contracts rather than replacing them.
• Architecture and platform standards: Because guards and providers are configurable, it supports supporting multiple user populations (customer vs. admin vs. partner) with distinct models and session rules in one codebase — a common requirement that surfaces late and is expensive to retrofit.
• Vendor and cost decisions: Zero licensing cost, no per-MAU identity pricing, no third-party auth vendor lock-in or contract negotiation. This is material for products with large or unpredictable user bases where hosted identity providers price on monthly active users.
• Technical debt and maintenance planning: A key product-level signal is that this is a read-only subtree split of laravel/framework and is explicitly not intended for standalone or direct dependency use. The decision to record is not "add this package" but "standardize on laravel/framework and its native auth," which prevents a future migration when someone mistakenly pins the split package directly.

When to Consider This Package

Strong fit:

• The product is built on Laravel (or a Laravel-adjacent stack that already pulls in the framework), and the team is comfortable with Laravel conventions — facades, service container, middleware, config/auth.php.
• Authentication is table stakes, not a differentiator: SaaS apps, internal tools, admin backends, marketplaces, customer portals.
• You need standard flows first — credential login, registration, password reset, email verification, remember-me, route protection — and want room to extend later via Sanctum, Passport, Fortify, or Socialite.
• You need multiple guards or user providers, or you expect to add them.
• Security review, auditability, and long-term maintainability outweigh the appeal of a bespoke or exotic auth approach.

Look elsewhere or rethink:

• The stack is not PHP, or is PHP without Laravel (Symfony, CodeIgniter, Slim). The package is welded to Laravel's container and config; wiring it up manually is more work than a native alternative and contradicts its design.
• The product is a deliberately lightweight microservice where pulling in the full framework dominates the dependency footprint — a managed identity service (e.g., Firebase Auth, Auth0, Cognito) may be the better structural fit.
• Requirements go materially beyond what the credential/session/token model expresses well: decentralized identity, biometric verification, or regulatory flows with bespoke attestation and audit requirements outside Laravel's scope.
• The team has no Laravel depth and no appetite to adopt its conventions — the productivity and security arguments both depend on the framework being used idiomatically.
• You are tempted to composer require illuminate/auth directly. Don't; that's an anti-pattern. If the only way to use it is standalone, the answer is no.

How to Pitch It (Stakeholders)

Executives: "Authentication is a required feature on every product we ship, and it is also one of the highest-risk areas to build ourselves. This is the built-in auth system of Laravel, the most widely used PHP framework, maintained upstream, MIT-licensed, and audited by a very large community. Using it means our login, registration, password reset, and session handling are production-grade from week one — no license fees, no per-user identity vendor pricing, and no bespoke security code for us to own and defend in an audit. Concretely: it compresses the auth portion of an MVP from weeks to days, removes a class of security and compliance exposure, and frees engineering to work on the features customers actually pay for. The trade-off is a commitment to Laravel as our stack — which is a decision we've already made in practice."

Engineering: "illuminate/auth is the authentication layer inside laravel/framework — a read-only subtree split, so we consume it by using the framework, not by requiring the package directly. It gives us guards, providers, and the Auth facade with session management, password hashing, and token auth already wired into middleware, routing, and the container. Standard flows come for free; anything custom — extra guards, custom Authenticatable models, JWT or OAuth, MFA — is an extension of documented contracts (Auth::extend(), custom PasswordBroker, config/auth.php), not a fork. Sanctum, Passport, Fortify, and Socialite all build on these same primitives, so our auth roadmap is additive rather than a rewrite. Two things to internalize from day one: never add the split package as a direct dependency, and never trust Auth::user() without an Auth::check() or the auth middleware — silent null is the most common bug in this area. Net effect: less boilerplate, one consistent pattern across services, and a large community to lean on when something behaves unexpectedly."