Php Auth Core Laravel Package

Product Decisions This Supports

• Build vs. buy for authentication. Auth is non-differentiating infrastructure—the classic "buy or borrow" candidate. This package is a candidate vendor for the login/session/credential layer, so it belongs in the build-vs-buy evaluation even if it ultimately loses.
• Scope of the auth surface we commit to. Before adopting anything, the PM must decide which capabilities are in-scope (registration, login, password reset, email verification, session vs. token, MFA, SSO/OIDC, rate limiting, audit logging). This package advertises only "Provides Authentication" with no feature matrix, so it cannot yet anchor a roadmap—only a diligence checklist.
• Risk posture of the identity layer. Auth is the highest-blast-radius subsystem in the product; a defect is a breach, not a bug. Adoption decisions here should be gated on maintenance signals (stars, dependents, release cadence, security policy), which for this package are all near-zero.
• Roadmap sequencing. If we build auth in-house, we defer differentiating work; if we outsource, we accept supply-chain and licensing exposure. This package's profile argues for keeping auth on the framework-native path and spending the saved cycle on product differentiation.
• Vendor and dependency governance. A dependency with 0 stars, 0 dependents, and a single maintainer is an unpriced liability. This triggers a standing decision: what evidence bar must a dependency clear before it enters the identity path?
• Due-diligence finding worth escalating. The supplied documentation is a generic Symfony project/agent workflow (Flex recipes, WebTestCase, devbox, bin/console), not package documentation. It describes how to work in a Symfony codebase, not what this package does, how to install it, or what its API is. For a Laravel-targeted adoption this is a documentation gap and a signal the package is not being actively documented for consumers.

When to Consider This Package

Consider it only when all of the following hold:

• The product is AGPL-3.0-compatible—i.e., it is itself AGPL, or the auth code is fully isolated behind a process/network boundary with legal sign-off. This is the single hardest gate; AGPL's network-use clause is a serious problem for SaaS and closed-source distribution.
• It is a throwaway prototype or internal tool where auth correctness is low-stakes and the code can be replaced wholesale.
• The team is willing to vendor/fork the source and own it, including security patches—i.e., treating it as a code donation rather than a maintained dependency.
• The team has no existing framework auth story and no appetite to build one, and a time-boxed spike shows the API is clean and testable.
• A code and security review has been completed, since there is no community, no dependents, and no evidence of external scrutiny.

Look elsewhere when:

• The platform is Laravel—use the native stack instead: Breeze/Jetstream for scaffolding, Fortify for headless auth, Sanctum for API tokens/SPA, Passport for full OAuth2. These are first-party-adjacent, MIT-licensed, and have massive usage.
• The platform is Symfony—SecurityBundle plus an authenticator is the idiomatic answer, consistent with the project conventions in the provided docs ("Auth: SecurityBundle, and which authenticator?").
• The product needs MFA, SSO/SAML/OIDC, SCIM, or enterprise RBAC—this package gives no indication it covers any of that; a specialist identity provider is the correct buy.
• You need regulatory assurance (SOC 2, PCI, HIPAA) or a security disclosure process—none is evidenced.
• You need predictable maintenance: 0 stars, 0 dependents, and a release date in the future (2026-10-14) indicate an unproven, possibly pre-release artifact. Treat the metadata as unreliable and verify the tagged release actually resolves.
• Licensing must be permissive (MIT/Apache-2.0) for downstream redistribution.

How to Pitch It (Stakeholders)

To executives (decision summary): We evaluated xver/php-auth-core as a shortcut to ship authentication. Recommendation: do not adopt at this time. Three reasons: (1) Legal—it is AGPL-3.0, whose network-use clause can obligate us to release source for any service that uses it; that is a business risk, not a legal technicality. (2) Assurance—zero stars, zero dependents, no security or disclosure process, and a release date that does not resolve to a trustworthy artifact; we would be the first and only production user of our own login system. (3) Documentation—the material supplied documents a Symfony development workflow, not this package; we cannot even confirm its feature set or API without reading the source. Authentication is not where we should be an early adopter. The framework-native path (Laravel Fortify/Sanctum/Passport; Symfony SecurityBundle) is free, permissively licensed, widely deployed, and supported by people whose job is to keep it correct. We keep the auth roadmap on that path and revisit third-party identity only for genuine differentiators like SSO/MFA, where buying from an established vendor is warranted.

To engineering: Treat this as a code-review candidate, not a dependency. If someone wants to spend a spike on it, time-box it: read the source for credential handling, password hashing (must be password_hash/Argon2id or bcrypt—no custom crypto), session fixation defenses, CSRF, timing-safe comparisons, and rate limiting. Confirm it installs, runs on our PHP version, and has tests that exercise real request flows. Absent that, this is a no-go. The default position is to use the framework's security component and spend our engineering budget on the product.

Ask: Approve the framework-native auth approach, and require a documented diligence bar (license compatibility, maintainer health, security process, real docs) before any third-party package enters the identity path.