Authentication Bundle Laravel Package

Product Decisions This Supports

• SSO as a v1 feature bet. Informs whether "Sign in with Google" ships as an onboarding feature for internal tools, partner portals, or Workspace-based staff apps, where Google identity is a credible proxy for "employee" or "verified business user."
• Build vs. buy vs. integrate. Places the choice in the "integrate" bucket — a thin wrapper over Google's OAuth2 flow, not an identity platform. The real decision it forces is whether to own an OAuth implementation at all versus adopting a maintained client library (Laravel Socialite, league/oauth2-google, KnpUOAuth2ClientBundle) or outsourcing to an IdP (Auth0, WorkOS, Keycloak).
• Activation and support-cost modeling. SSO typically lifts signup completion and reduces password-reset tickets. This package lets you estimate integration effort for that bet cheaply — a 1–2 day spike — before committing engineering time.
• Roadmap constraint to surface now. Single-provider, Google-only. No SAML, no OIDC multi-provider routing, no Azure AD/Okta, no SCIM provisioning, no per-tenant IdP configuration. If enterprise SSO is on the 12-month roadmap, this is a stopgap, not a foundation, and adopting it creates migration debt you should price in today.
• Platform framing. Forces the call between identity as "a feature we bolt on" versus "a platform capability we standardize." A zero-signal, zero-dependent bundle implies the former; a corporate IdP strategy implies the latter.
• Stack reality check that changes the decision. Despite being catalogued as a Laravel/PHP package, this is a Symfony bundle by namespace and structure. For a Laravel codebase the answer is almost certainly Socialite; the package is only a candidate for a Symfony service. Record the adopt/reference-only/reject decision per application, not once globally.

When to Consider This Package

Consider it when all of the following hold:

• The application is Symfony, not Laravel — bundle registration, DI container, and config tree are Symfony-shaped, and you have confirmed version compatibility against your composer.json.
• Google Workspace is the sole identity provider and will remain so for the product's horizon.
• Scope is an internal tool, admin console, or short-lived MVP where a login outage is inconvenient rather than revenue-impacting.
• The team is prepared to vendor or fork and own the code: read the OAuth flow end to end, add tests, and track Google API and Symfony-major changes themselves.
• You have a named owner, a working contact at RetItalia, and a documented fallback path to your existing login.
• No PII, payment, or regulated data sits behind the login without a separate security review covering state/PKCE, redirect-URI allowlisting, token and refresh-token storage, and session-fixation defenses.

Look elsewhere when:

• Laravel: use Laravel Socialite with a guard/listener. Do not force a Symfony bundle into a Laravel app for auth.
• You need a maintained dependency. Zero stars, zero dependents, no visible release or security cadence means no CVE coverage, no compatibility guarantees across Symfony majors, and a bus factor of roughly one — a supply-chain risk for anything customer-facing.
• Multi-provider or enterprise SSO: SAML, OIDCfederation, IdP-initiated flows, SCIM, tenant-level configuration — none of that is here. Go to WorkOS, Auth0, Keycloak, or Symfony's HWIOAuthBundle / KnpUOAuth2ClientBundle.
• You need SLAs, support contracts, or an audited auth path. This is not a vendor.
• Compliance scope (SOC 2, HIPAA, PCI) demands provenance and patch commitments an unstarred package cannot provide.
• You need documentation and a hiring pool. No public docs and no Stack Overflow corpus means every new engineer ramps by reading source — budget one to two days minimum.

How to Pitch It (Stakeholders)

To executives: Google sign-in is a cheap, visible activation win — fewer passwords, fewer reset tickets, faster onboarding, and a measurable reduction in support load. This package is not a purchase decision; it's a free starting point that gets us to a demo in days. Recommend a time-boxed spike of 1–2 days with a hard go/no-go gate, not a commitment. Frame the risk plainly: a dependency with no adoption signal is code we may have to own forever, and authentication carries the highest blast radius of anything we ship. It is the right call for internal tools; it is the wrong call for customer-facing or regulated surfaces.

To engineering: This is a Symfony bundle — Laravel teams should default to Socialite and stop here. Symfony teams get a small Google-OAuth2 convenience wrapper, but should plan to fork it. The spike deliverable is not an integrated login; it is three artifacts: (1) an ADR recording build-vs-reuse and the fallback (native knpu/oauth2-client or Google's official client), (2) a provider adapter interface so SSO can be swapped without touching call sites — this is the single most valuable artifact and caps the cost of abandonment, and (3) an internal runbook covering configuration, a failure-mode table, and rollback steps. Audit the authorization-code flow end to end: state/PKCE, redirect-URI allowlisting, token and refresh-token storage, and session-fixation defenses. Pin the bundle to an exact tag or commit SHA and pin the transitive OAuth2 client explicitly — do not rely on its constraint ranges. Expect one to two days of ramp-up per engineer from source reading alone.

Framing the recommendation:

• Adopt only for internal, low-blast-radius Symfony apps with Google as the sole IdP, behind a feature flag, rolled out to internal users first.
• Trial as a reference implementation to accelerate a spike, with an explicit decision gate on "do we fork or replace" before any production integration. Anything before that gate is sunk cost if the package is rejected.
• Avoid for customer-facing auth, regulated data, or anywhere SSO is a multi-year platform bet.
• Default alternative: Socialite (Laravel) or KnpUOAuth2ClientBundle / league/oauth2-google (Symfony) — roughly the same integration effort with a far better maintenance signal.