Laravel Trustup Io Authentification Laravel Package

Product Decisions This Supports

• Build vs. buy (auth): This package is a thin integration layer onto a centralized TrustUp.io auth service, not a homegrown auth stack. Adopting it means login, session and token handling are not rebuilt app-by-app — a "buy/centralize" call that removes auth from every new product's critical path.
• Roadmap — SSO across the Laravel portfolio: Enables a single identity source across multiple Laravel/PHP services, which is the prerequisite for cross-product navigation, shared user profiles, and consistent access control.
• Feature go/no-go: "Add login" to a new internal or customer-facing Laravel app becomes a config + middleware task rather than a scoped project — shortens estimates and de-risks launches.
• Environment strategy / dev velocity: The release makes the auth service URL configurable (TRUSTUP_IO_AUTH_DOCKER_URL) and scheme-correct for Docker. That is a direct enabler for ephemeral preview apps, QA stacks and local Docker-based development pointing at a self-contained auth container — fewer shared-staging bottlenecks, more parallel work.
• Dependency & security hygiene: Tracking Guzzle 7.13+ means the package is maintained against upstream, so keeping the fleet on a supported, patched HTTP client doesn't require forks or version pins. This is a recurring maintenance-cost line item, not a one-off.
• Risk to price in: Centralized auth makes availability a shared dependency. Any roadmap that leans on this package should carry an SLO/fallback conversation (cached sessions, degraded-mode behavior) rather than assuming per-app auth isolation.

When to Consider This Package

Adopt when:

• More than one Laravel/PHP service needs to share one identity and session source.
• The organization has already standardized on the TrustUp.io auth service — this package is the sanctioned client, and forking it is the worse option.
• You need per-environment auth endpoints (Docker, preview apps, staging, on-prem) rather than a hardcoded production URL.
• You are on, or plan to move to, Guzzle 7.13+ and want compatibility handled upstream instead of via pins or vendor patches.
• You want auth treated as platform surface with a versioned upgrade path rather than copy-pasted middleware.

Look elsewhere when:

• It's a single Laravel app with ordinary authentication — Breeze/Fortify/Jetstream is materially cheaper and has no external dependency.
• The consuming services are not Laravel/PHP; talk to the auth service directly over its protocol instead of pulling in a framework-specific client.
• You need to own consumer-facing identity concerns — social providers, MFA policy, consent, compliance certifications. This is an integration layer, not an identity provider, and should not be presented as one.
• The auth service's role/tenant model doesn't match your product's authorization needs; retrofitting org-level permissions onto a client package is a common and expensive trap.
• Bus factor on an internal package is a blocker — require a named maintainer and a stated support window before it becomes a dependency of revenue-facing products.

How to Pitch It (Stakeholders)

For executives: One auth integration shared across all Laravel products, so login is built and maintained once instead of per app. This release (v4.0.1) is pure maintenance: no API changes, no migration. It fixes how the Docker auth service URL is constructed so it keeps working with newer Guzzle versions — meaning we can stay on supported, security-patched dependencies without forking anything. The strategic point is that identity is now a platform component with an owner and a release cadence, not duplicated glue code in every repo.

For engineering: Patch release, non-breaking. It adds a URL scheme to the Docker auth service endpoint and exposes it via TRUSTUP_IO_AUTH_DOCKER_URL, resolving URI handling under Guzzle 7.13+. Actions: bump the dependency, set the new env var in Docker/preview/CI environments, and smoke-test the local login flow. No code changes required beyond configuration. Treat this package as shared platform surface — track its releases, avoid pins and forks, and raise Docker/dev-environment gaps upstream rather than patching locally.