Steamauth Laravel Package

Product Decisions This Supports

• Feature go/no-go for "Sign in with Steam." This package exists to solve exactly one problem: authenticating a user against Steam's OpenID 2.0 endpoint and resolving a verified SteamID64. That SteamID64 is the prerequisite for every Steam-keyed feature on the roadmap — gated content, ownership verification, inventory display, verified-trader badges, leaderboards, and match-history tie-ins. If Steam identity isn't on the roadmap, there is no reason for this package (or this work) to exist in the stack.
• Build vs. buy, resolved toward build. The scope is bounded: an OpenID 2.0 redirect, an assertion verification round-trip, and a claimed_id → SteamID64 extraction. Ten stars and zero dependents means no community QA and no de facto maintenance channel. The value of adopting this as a dependency is low relative to the cost of inheriting an unmaintained one. A PM decision to "write the ~150-line adapter ourselves" is defensible and probably correct; treat this repository as a reference implementation, not a dependency.
• Account-linking strategy — primary vs. secondary identity. This package forces the question early. Is Steam a primary login, or a secondary credential linked alongside email/OAuth? Most gaming products want Steam as a linked identity, which changes the data model (one user, many identities, a nullable unique steam_id) far more than it changes the auth code. The bundle ships no account-linking primitives; that is a design decision we own, and it should be settled before engineering starts.
• Roadmap sequencing. Verified Steam identity is a hard dependency for downstream Steam features (inventory, trading, entitlements). It is a small, cheap enabler that unblocks later work — a good candidate for a low-risk sprint slot rather than a headline initiative.
• Vendor-risk posture as an explicit estimate input. Low adoption and no visible maintenance cadence mean any adoption is effectively "we own this code now." That support-cost delta belongs in the build estimate, not waved away as "it's just a composer require."
• Scope discipline on the Steam integration. This package authenticates; it does not call the Steam Web API. Inventory, owned games, player summaries, and bans are a separate integration with a separate estimate. Keeping those distinct prevents the classic scoping error of assuming "Steam login" includes "Steam data."

When to Consider This Package

Consider it only when all of the following hold:

• The stack is Symfony, not Laravel. The repository is SteamAuthBundle — a Symfony bundle. The listing as a generic Laravel/PHP package is misleading. In a Laravel codebase there is no ServiceProvider, no facade, no Auth::driver('steam'); its wiring assumes Symfony's DI container, security firewall, event dispatcher, and HTTP kernel. At best you extract the handshake logic and rewrite the integration layer.
• The Symfony version aligns with the bundle's era. "Bundle"-style packages typically target Symfony 2/3 conventions; modern Symfony (5/6/7) uses different bundle and autowiring patterns, so budget rework.
• Steam is a secondary identity, or the product can tolerate a single-provider login path.
• You explicitly accept owning the code: security review, dependency pinning, vendoring, and patching are on us — with a named internal owner.

Look elsewhere — or build in-house — when:

• You are on Laravel. Use a Socialite Steam provider (e.g., socialiteproviders/steam) or a small OpenID client. The integration cost of porting this bundle exceeds writing the adapter, and you avoid contaminating the dependency graph with stale Symfony pins.
• You need Steam Web API data (owned games, inventory, player summaries, bans). Separate integration, separate estimate.
• You need maintenance guarantees, security responsiveness, or a supported upgrade path. Zero dependents and low stars means no community validation on the highest-blast-radius surface in the app.
• You need OAuth 2.0 / OpenID Connect semantics, token refresh, or scopes. Steam's OpenID 2.0 flow is deliberately minimal, and this package reflects that — plus it inherits the risk that Valve sunsets a deprecated protocol with no drop-in replacement.
• You require SSO across multiple providers with unified session handling. That's an identity-layer decision, not a bundle decision.

How to Pitch It (Stakeholders)

To executives: "Sign in with Steam" is a cheap, well-understood unlock for our gaming-facing features — it lets us verify a user actually controls a Steam account and key our data to their SteamID, which is the foundation for inventory, trading, and entitlement features later. The off-the-shelf option here is a small, MIT-licensed Symfony bundle with essentially no community adoption (10 stars, zero downstream dependents), which means we'd inherit full maintenance and security responsibility anyway. Recommendation: treat it as a reference design and implement the authentication flow in-house — roughly a 1–2 day engineering task — so we avoid an unmaintained dependency in a security-sensitive path while shipping on the same timeline. Treat the Steam Web API integration (inventory, profiles) as separate, later work.

To engineering: The scope is narrow. Steam uses OpenID 2.0 — a redirect out with checkid_setup, a verification round-trip with check_authentication requiring is_valid:true, and strict extraction of the SteamID64 from openid.claimed_id (regex-anchored to steamcommunity.com/openid/id/<17 digits>). This bundle is Symfony-specific (bundle-era conventions, likely Symfony 2/3), so on Laravel it is a port, not an install — realistically an extraction of ~40–60 lines into a SteamAuthService plus a controller, with the Steam endpoints kept config-driven. Compare against a maintained Socialite Steam provider on evidence, not on this package's existence. Plan to own the code: pin dependencies, vendor rather than track a moving target, and add tests around signature verification, return_to/realm binding, and replay protection. Ship behind a feature flag with a non-Steam fallback path, and treat the security review — replay, return_to tampering, session fixation, account-linking collisions — as a release gate, not a cleanup task.