Sso Helper Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy for SSO: This package is a thin Laravel integration layer for an existing SSO provider rather than a homegrown auth stack. v4.0.0 makes the "buy/consume" path materially cheaper to defend: dependency CVE exposure is now enforced by Composer rather than left to team discipline, so the security review burden of not building SSO in-house drops.
• Platform lifecycle planning: The v4 support matrix (PHP 8.2–8.5, Laravel 10–13) is the clearest signal yet about which framework versions the vendor will keep patching. Treat it as an input to your Laravel upgrade roadmap, not just an auth decision — staying on Laravel 8/9 now forces you onto a frozen v3.x line that will stop receiving security work.
• Security/risk roadmap item: v4 explicitly pins guzzlehttp/guzzle to ^7.15.2 and adds conflict rules blocking vulnerable releases of symfony/http-foundation, symfony/mime, symfony/http-kernel, phpseclib/phpseclib, nesbot/carbon, firebase/php-jwt, and others. If your portfolio carries any of these transitively, adopting v4 is one of the cheapest ways to close them — composer audit is stated clean at both lowest and highest resolvable dependency sets.
• Upgrade cost estimation: "No code changes are required in your application" plus a single composer require is a low-risk, low-estimate change. This is a candidate for a maintenance sprint rather than a dedicated epic — useful when sequencing against other platform work.
• Scope boundary confirmation: The package handles SSO plumbing only. Don't let it creep into the roadmap as an identity platform; provisioning, SCIM, role mapping, and MFA policy remain separate decisions.

When to Consider This Package

Adopt when:

• You are on Laravel 10–13 and PHP 8.2+, or can get there — v4 is explicitly built for that window.
• You need SSO against the provider this package targets and want a maintained integration rather than custom middleware you own forever.
• Your team's security posture requires dependency-level CVE hygiene (audit-clean installs, enforced minimums) — v4 gives you composer audit cleanliness out of the box, including blocking CVE-2025-64500 and CVE-2024-50345 in symfony/http-foundation.
• You are doing a routine dependency-hygiene pass and want a single change that raises many transitive minimums at once.

Look elsewhere or defer when:

• You are still on Laravel 8 or 9 or PHP < 8.2. v4 is a hard break; you'd pin tekinfopg/sso-helper-laravel:^3.0 and accept that the v3 line is now a dead end with no forward security path. That is a platform-debt decision, not an auth decision — escalate it as such.
• You need a general-purpose identity provider (social login breadth, SCIM, policy engine) — this is a helper for a specific SSO flow.
• You cannot tolerate a major-version bump in your dependency graph this cycle: even with no application code changes, the raised minimums can conflict with other pinned packages and force unrelated upgrades. Validate resolution in a branch before committing.
• Your org requires vendor provenance/attestation on releases — note this release is marked as generated with Claude Code; confirm that meets your supply-chain review bar.

How to Pitch It (Stakeholders)

To executives (one line): A free, low-effort upgrade that closes a batch of known dependency vulnerabilities and confirms our Laravel/PHP versions stay supported — no application code changes.

To engineering leadership: v4.0.0 is a security and support-boundary release, not a feature release. It raises minimum dependency versions to close known CVEs (Guzzle and eight transitive packages including Symfony HTTP Foundation), adds Composer conflict rules so vulnerable versions cannot be installed alongside it, and verifies composer audit is clean at both the lowest and highest resolvable dependency sets. Support is now PHP 8.2–8.5 against Laravel 10 through 13, tested across PHP 8.2/8.3/8.4/8.5 on lowest (Laravel 10.0) and highest (12.x/13.x) resolutions. Breaking changes are platform-level only: PHP < 8.2 and Laravel 8/9 are dropped, with v3.x remaining available for anyone not yet migrated. Upgrade is a one-line composer require tekinfopg/sso-helper-laravel:^4.0 with no application code changes.

To the security reviewer: The concrete win is that the package now refuses to install alongside vulnerable dependency versions rather than merely recommending safe ones — the control is enforced at the resolver, not in documentation. Audit is clean at both dependency extremes. The caveat to check: the release is machine-generated, so confirm it went through your normal review path, and verify the conflict list doesn't collide with packages you've pinned intentionally.

Ask: Approve as a maintenance-window change with a short validation branch (dependency resolution + SSO login smoke test), and confirm our Laravel version is inside the 10–13 window so we are not stuck on the unsupported v3 line.