Sso Auth Bundle Laravel Package

Product Decisions This Supports

• Framework fit is the first decision, and this package fails it. Despite the framing as a Laravel/PHP package, webnet/sso-auth-bundle is a Symfony2 bundle. It cannot be dropped into a Laravel application without a rewrite. Any roadmap item premised on "reuse this for our Laravel SSO work" should be closed now — the effort to adapt it exceeds writing the integration from scratch against a maintained library.
• Signal, not a solution. The domain (SSO for PHP web apps) is genuinely valuable; the artifact is not. Use this repo only as evidence of demand — e.g., "teams still search for turnkey SSO bundles" — never as a build dependency. Its scores (1 star, 0 dependents, score 0.065) describe a package with no ecosystem validation, not a niche gem.
• Build vs. buy leans hard to "buy" — but not this. If SSO is on the roadmap, the buy decision should target a maintained IdP integration (Symfony's native authenticator + league/oauth2-* or a SAML bundle; Laravel Socialite/Passport on the Laravel side) or an external IdP (Keycloak, Entra ID, Auth0). This package sits in the trough between: too stale to trust, too thin to fork.
• Supports a "legacy freeze" decision, not a feature decision. The one legitimate use is a Symfony 2.x app already in maintenance-only mode, already using Webnet's SSO provider, where the alternative is re-architecting auth. That is a risk-acceptance decision, not a product bet.
• Use cases it does not support: customer-facing login, anything under SOC 2 / ISO 27001 scope, PHP 8 migrations, multi-tenant auth, or any surface where an unpatched auth dependency is a liability rather than an inconvenience.

When to Consider This Package

Consider it only when all of the following hold:

1. The application is already on Symfony 2.x or early 3.x and is explicitly frozen (security-fix-only, no new features).
2. You are already a Webnet SSO customer and the bundle's protocol assumptions match your IdP configuration — otherwise you are integrating against an undocumented, unmaintained contract.
3. The exposure is internal-only (back-office, admin tooling) with a small, known user population.
4. You have accepted, in writing, that the last release was 2018-06-26 and that no security patches will arrive — Symfony 2 reached end of life in November 2018, so the surrounding framework is equally unpatched.
5. Someone on the team can read and patch the bundle's source in-house if the IdP changes.

Look elsewhere when any of these are true — which is nearly always:

• You are on Laravel (framework mismatch; this is a Symfony bundle with Symfony DI, routing, and security-firewall assumptions).
• You are on Symfony 5/6/7 — the security component was rewritten (Guard → Authenticator), and this bundle targets the pre-Guard era.
• The app is new, customer-facing, or in a compliance scope.
• You need maintained protocols (OIDC, modern SAML), MFA, or token refresh.
• You want a dependency with a track record — 1 star and 0 dependents means zero downstream validation and no community to catch regressions.

Better defaults: Symfony's built-in security authenticators plus league/oauth2-client or hslavich/OneloginSamlBundle; Laravel Socialite, Sanctum, or Passport; or offload to a hosted IdP entirely.

How to Pitch It (Stakeholders)

To executives: We evaluated webnet/sso-auth-bundle as a shortcut for SSO and are recommending against adoption. It is a single-maintainer Symfony2 bundle with one star, zero dependent projects, and no release since June 2018 — the same year Symfony2 itself went end of life. For a Laravel codebase it is not even compatible. Adopting it would put authentication — the highest-blast-radius surface in any product — on an unpatched dependency with no support path. The cost of a bespoke integration is small and bounded; the cost of an auth incident is neither. Recommendation: fund a short spike against a maintained IdP integration instead, and treat this package as a demand signal rather than a candidate.

To engineering: Treat the repo as a reference implementation only — it can show you the shape of an SSO handshake in a Symfony context, but do not vendor it. If a legacy Symfony 2 app genuinely needs it, isolate it behind our own auth interface so it can be swapped, pin the dependency, and log it in the risk register with an owner and a removal date. For the Laravel work, budget the integration directly: Socialite or an OIDC client against a real IdP, with tests around the callback and session lifecycle. Do not spend cycles porting a Symfony DI bundle into Laravel's container — that is a false economy.

One-line ask: Approve closing this as "evaluated, rejected — framework mismatch and unmaintained," and redirect the effort to a maintained SSO integration.