Auth Laravel Package

Technical Evaluation

Architecture fit — low, with a category mismatch. This is a plugin for webman, the Workerman-based resident-process PHP framework, not a Laravel package. It almost certainly depends on workerman/webman-framework, the plugin/ config convention (config/plugin/webman-tech/auth/...), and webman's PSR-15-style middleware contract (Webman\MiddlewareInterface). Laravel's auth surface — AuthManager, guards, Illuminate\Contracts\Auth\Authenticatable, service providers, HTTP kernel middleware — has no adapter here. There is no Auth::extend() driver, no Laravel service provider, and installing it into a Laravel app would drag in a competing framework runtime and container. Treat "Laravel/PHP package" in the brief as an error to correct with stakeholders before any estimation.

Integration feasibility — effectively zero as a library, moderate as a reference or sidecar. Only three honest paths exist: (1) harvest it as a design reference for webman-side auth and do not install it; (2) run webman as a standalone auth service and have Laravel call it over HTTP; (3) use Laravel-native auth (Sanctum/Passport/Fortify) or a vetted standalone (firebase/php-jwt, league/oauth2-server). Path 2 is the only one where this package appears in production, and even then it is a small dependency inside a service you fully own.

Technical risk — high, concentrated on provenance. 14 stars, a stub description, an unknown repository, and a composite score of 0.13 indicate a package we cannot verify: no readable source, no visible CI, no license confirmation, no security disclosure channel, no release history beyond a single 2025-07-15 tag. Auth is the highest-blast-radius component in any stack — token issuance, password hashing, session fixation, timing-safe comparison, rate limiting, key rotation. A low-adoption auth library is a build-vs-buy decision that defaults to "build" or "buy from a maintained vendor," not "adopt from an anonymous GitHub repo."

Key questions to resolve before any commitment:

• What is the actual auth model — session, JWT, opaque tokens, OAuth2? Does it issue, refresh, and revoke?
• Does it support signing-key rotation with an overlap window, and are tokens verifiable locally (JWKS cached) or only via a round trip?
• Which webman major version and PHP versions are supported? Is the 2025-07-15 artifact a real tagged Composer release or a branch snapshot?
• Who maintains it, under what license, and is there any test suite or CI configuration?
• What is the dependency tree — does it pull illuminate/*, and at which versions?
• Is there a rate-limiting / lockout story, or is that left to the caller?

Integration Approach

Stack fit — structurally different execution model. Laravel is shared-nothing: every request bootstraps a container, and request state dies with the process. webman is resident memory: workers boot once, hold singletons and static state across requests, and reload on php start.php reload. Any auth cache, key store, or user object held in a static property behaves differently and can leak across requests or tenants. If the team is Laravel-fluent, this is the single most expensive mental-model shift, and it is a correctness risk in auth code specifically.

Migration path — do not attempt a code migration. Recommended sequence:

1. Verify provenance: clone, read the source end to end, confirm license and dependency tree, and record a threat model. If the repo stays unknown, stop here.
2. If the auth model is sound, extract the pattern, not the package, and reimplement the minimal surface in Laravel behind a Guard driver or a Sanctum-compatible token flow.
3. If a polyglot split is genuinely desired, stand up webman as an isolated auth service with an OpenAPI contract; Laravel becomes an HTTP client. Keep it out of the monolith's Composer graph entirely.
4. Only if the platform is already webman-first: install pinned, vendor the source into the repo, and own the fork.

Compatibility — likely conflict, not merely friction. A Laravel install attempt will collide on shared transitive packages (psr/container, psr/http-message, symfony/* minor versions) and on framework-level assumptions (config repository, container bindings, exception handler). Pin exact versions, verify PHP minor compatibility, and run composer why-not before assuming co-installability. Plan for the plugin's config directory to be meaningless outside webman.

Sequencing — contract before code. Fix the token format and validation contract first (claims, TTL, refresh semantics, revocation list location), then choose the implementation. That ordering makes the build-vs-adopt decision reversible and lets you swap this package out without touching callers. Shadow-mode the chosen path against existing login flows before cutting over.

Operational Impact

Maintenance — you inherit the fork. With 14 stars and no visible repo, the bus factor is one and possibly zero. There will be no upstream patches for PHP minor releases, no CVE feed, and no security advisories. Budget ongoing engineering ownership, not a one-time integration cost. If the repo stays unverifiable, ownership cost is unbounded and the answer is no.

Support — community-only, and auth incidents are P1. Escalation path is GitHub issues on a low-traffic project. There is no vendor SLA. For a component that gates every authenticated request, that is a business-continuity gap that needs an explicit executive sign-off if pursued.

Scaling — the sidecar model scales; the coupling does not. Workerman workers are cheap and handle concurrency well with far less per-request overhead than php-fpm, so an auth service on webman will scale horizontally without drama. The risk is topological: a synchronous validation hop on every request turns auth into a single point of failure for the whole product. Mitigate with local token verification (cached JWKS), short-lived tokens, and a documented degraded mode. Add Redis-backed revocation and rate-limit state; do not keep it in worker memory.

Failure modes to design against:

• Auth service unavailable → total product outage; needs cached-key local validation and a circuit breaker.
• Key rotation without an overlap window → mass token invalidation at rollout.
• Clock skew between issuers and verifiers → intermittent 401s that are hard to reproduce.
• Session/revocation store loss → either forced global logout or, worse, silent acceptance of revoked tokens.
• Static state in resident workers → cross-request or cross-tenant identity bleed; requires explicit audit.
• Hot reload dropping in-memory key/config state mid-traffic.
• Absent rate limiting → credential stuffing goes undetected because the framework does not provide it.

Ramp-up — 2–4 weeks for a mid-sized team, plus ops retraining. Developers must unlearn facades, Eloquent defaults, and per-request bootstrapping, and learn explicit middleware registration and plugin/ config. Operations must move from php-fpm pool tuning to Workerman process supervision, reload semantics, and worker memory monitoring — a different on-call runbook.

Recommendation. Decline adoption for a Laravel stack. Score 0.13 is directionally correct. If webman is already the platform, treat this as an unvetted internal fork to be read, pinned, and owned — not a dependency to trust.