Auth Laravel Package

Product Decisions This Supports

• Auth feature scoping and build-vs-borrow calls. smorken/auth is a thin Laravel auth helper covering login, registration, password reset, guards/providers, and route-protection middleware. It is an input to the decision of how much of the authentication surface your team builds versus borrows — not a justification to outsource identity itself.
• Roadmap gating for user-management features. If you are planning RBAC, admin provisioning, gated content, or a first customer-facing login, this package gives you a cheap way to prototype the auth flow before committing budget to a durable IAM direction (Breeze/Fortify/Jetstream, Sanctum/Passport, or an external IdP).
• Prototype-vs-platform triage. The adoption signals are effectively zero: Bitbucket-hosted (no Packagist), no stars, zero dependents, composite score 0, opportunity score 24.25. That profile makes it a spike/borrow candidate at best and a poor candidate for a platform commitment.
• Dependency-governance calibration. It is a useful reference case for the criteria your team should require before adopting any auth-adjacent dependency: license clarity, supported Laravel/PHP range, test suite, named maintainer, release cadence, and a security-advisory path.
• Explicitly not a decision-driver for: SSO/enterprise IAM (SAML, OIDC, SCIM), compliance-scoped auth (SOC 2, HIPAA, PCI), multi-tenant production launches, or any customer-facing authentication path. Those decisions should be made against Laravel's first-party stack and vendor-supported options.

When to Consider This Package

Consider it only when all of the following hold:

• Your application is on a Laravel version the package actually declares support for — verify composer.json constraints against your framework version before anything else. An unversioned helper is likely pinned to an older major.
• The need is a narrow, internal helper — a prototype, spike, throwaway branch, or internal tool — not a customer-facing production auth layer.
• You have read the source and are prepared to own a fork. With zero dependents and no visible maintenance, you are the maintainer of record the moment it enters the dependency graph.
• You have a security-review path for authentication code, and you can pin the exact commit and monitor it manually (no advisory feed or Dependabot coverage will watch a Bitbucket-hosted package).
• It adds something Auth, Gate, policies, Breeze, Fortify, or Sanctum genuinely do not — not just syntactic sugar.

Look elsewhere when:

• You need maintained, production-grade auth. Use Laravel's first-party options (Breeze/Jetstream/Fortify, built-in Gate/policies) and, for permissions, established packages like Spatie laravel-permission or Bouncer.
• You require audited, widely depended-upon code. The zero-star / zero-dependent / Bitbucket / single-maintainer profile is a supply-chain and bus-factor risk.
• Your stack already standardizes on Fortify, Breeze, Jetstream, Sanctum, Passport, or an external IdP — this package will duplicate or conflict with it.
• You need enterprise identity — evaluate dedicated IAM providers.
• You cannot pin, vendor, and monitor the dependency, or the license, last-commit date, open issues, or compatibility checks fail.

Adoption gate before any commit: confirm license, last-commit date, open issues, PHP/Laravel compatibility, test presence, and a named internal owner. If any of those fail, recommend against — and reimplement the specific helper internally under your own tests and license if the functionality is genuinely needed.

How to Pitch It (Stakeholders)

For executives: This is a small, single-maintainer Laravel authentication helper with essentially no adoption — no stars, no downstream dependents, a composite score of 0, and Bitbucket hosting that keeps it outside Packagist and standard security-advisory tooling. It is cheap to trial and expensive to depend on: no vendor, no community, no SLA, no maintenance guarantee, and a bus factor of one. My recommendation is not to standardize on it. At most, treat it as a short-lived prototype shortcut while we settle a first-party or well-supported auth direction. The strategic decision it informs — how we handle identity — belongs on the roadmap, and that decision should be made on durability, security, and supportability, not on convenience.

For engineering: Treat smorken/auth as a reference implementation, not a dependency. Read it for patterns around guards, providers, and route middleware, then build on Laravel's native auth (Gate, policies, Breeze/Fortify) with a maintained permissions package. The one question that decides everything is: what does this add that the framework does not already provide? If the answer is syntactic sugar, the risk is unjustifiable. If we do trial it, wrap it behind a single internal adapter (an AuthService facade) so call sites depend on our interface, pin the exact commit, vendor the source, assign an owner, and timebox the spike. Expect the realistic outcome to be reject or fork and own it — the spike exists to confirm or overturn that prior, not to build toward adoption by default. Do not introduce it into anything customer-facing without a security review and a fork-and-maintain plan; the silent failure modes (a Laravel upgrade breaking password-reset or remember-me flows, an unreported vulnerability, or the VCS reference becoming unresolvable and breaking clean builds for every consumer at once) are low-probability per quarter and high-impact when they land.