Laravel Api User Provider Laravel Package

Product Decisions This Supports

• Build vs. buy for microservice auth: Lets a Laravel service authenticate users it doesn't own. Instead of building a custom HTTP-based user provider or copying auth logic into every service, this package provides a pluggable UserProvider that resolves the current user from a remote/separate user service. That's a "buy" (adopt) decision that removes a few days of undifferentiated auth plumbing from the roadmap. The v1.0.9 Guzzle dependency bump doesn't change this calculus — it's plumbing maintenance, not new capability.
• Service decomposition / microservice migration: Directly supports a roadmap item where the monolith is split and user identity lives in one service while other Laravel services still need to authenticate and authorize requests. It's an enabler for the "extract auth service" milestone.
• Multi-service session/token strategy: Informs the architectural decision of whether each service calls the user service per request (this package's model) versus issuing self-contained JWTs or using a shared gateway. This affects latency, availability, and failure-mode planning.
• Feature parity across services: Makes it possible for multiple Laravel apps (admin panel, internal tools, new APIs) share the same user source, reducing duplicate registration/profile logic and keeping permissions consistent.
• Prioritization of auth consolidation: A cheap, low-risk way to prove out a consolidated identity layer before committing engineering budget to a full SSO/IAM platform.
• Dependency hygiene as a decision input: The only change in v1.0.9 is a Guzzle update. That tells us the package still compiles against a current Guzzle line but also that there is no feature roadmap, no security advisory handling, and no test/CI signal in the release note. Treat "maintained" here as "barely alive," and factor the cost of owning a fork into the estimate.

When to Consider This Package

Consider it when:

• You run multiple Laravel services and exactly one owns user records; the others need to authenticate against it.
• Your teams are already on Laravel's standard auth contracts and want a provider that plugs in without rewriting guards, middleware, or Auth::user() calls.
• You want a minimal, MIT-licensed, self-hosted solution rather than adopting a hosted identity vendor (Auth0, Cognito, Keycloak).
• The remote user lookup is simple and read-only (fetch user by ID/credential) and you can tolerate a synchronous HTTP call per resolution.
• You're prototyping the auth-extraction architecture and need something faster than a bespoke implementation.
• The new release's Guzzle constraint is compatible with your existing Laravel/PHP dependency graph — verify this first, since a Guzzle version bump can ripple into other packages and is the single most likely source of breakage in this upgrade.

Look elsewhere when:

• You need token issuance/verification, refresh flows, MFA, or social login — this is a user provider, not an identity platform.
• Your services are not PHP/Laravel (polyglot estates should standardize on JWT/OIDC or a gateway instead).
• You have strict availability or latency SLOs — a synchronous per-request call to a user service creates a hard dependency and a new single point of failure; JWT validation or caching layers are better.
• You require active maintenance and community support: 11 stars, 0 dependents, and a release history consisting of a several-year gap followed by a single "update guzzle" patch (v1.0.9) mean low adoption, no ecosystem validation, and no visible security-patch cadence. A dependency bump is not evidence of a maintenance commitment.
• You need guaranteed long-term support or vendor accountability — there is none here.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT) open-source component that lets our Laravel services authenticate users held by a single user service — a building block for consolidating identity as we split the monolith. It replaces custom auth plumbing with a standard adapter, saving days of engineering and reducing divergent login logic across apps. The trade-offs are unchanged and still the headline: it is a low-adoption project (11 stars, no known dependents), now with a single dependency-bump release (v1.0.9) after a long quiet period — that signals minimum viable upkeep, not active development. It also makes each authenticated request depend on the user service being reachable. Recommendation: use it as a low-cost spike or internal-only component, with an explicit exit path to JWT/OIDC or a managed identity provider if our scaling, availability, or compliance needs grow. It is not a strategic identity platform purchase — it's a tactical integration that we should own (fork/vendor) if we depend on it. Budget a small fixed maintenance allocation for that fork; the v1.0.9 bump is a reminder that someone (us) has to keep watching upstream dependencies.

To engineering: It's a drop-in UserProvider implementation so Auth::user() works in a service that doesn't own the users table. Pros: standard Laravel contracts, tiny surface area, easy to read and fork, no lock-in. Cons: synchronous remote lookup per resolution is a latency and blast-radius concern — plan caching and a circuit breaker, and define behavior when the user service is down. The v1.0.9 release only bumps Guzzle, so there are no new features, no breaking API changes, and no security content to evaluate — but check the new Guzzle constraint against our other dependencies before upgrading, and re-run the spike against our Laravel version and auth driver mix. Since the package has no meaningful maintenance cadence, vendor or fork it, pin the version, and review the HTTP call and error handling ourselves before production.