Iam Bundle Laravel Package

Product Decisions This Supports

• Auth build-vs-buy, scoped correctly. This is "buy the glue, not the IdP." The package supplies security implementations (user providers, authenticators, firewall/access-control wiring) on top of gdbots/iam abstractions, and — as of v5.1.0 — explicit integration with the Auth0 PHP SDK (auth0/auth0-php 9.x). The decision it informs is narrow and real: do we hand-roll Symfony security wiring against a gdbots-style identity model backed by Auth0, or adopt prebuilt wiring?
• IdP commitment is now part of the decision, not adjacent to it. v5.1.0's dependency on auth0/auth0-php 9.x makes Auth0 a first-class assumption. If the product isn't on Auth0 (or willing to be), the package's value drops sharply. This belongs in the ADR alongside the gdbots commitment.
• Stack-fit gate — decide this first. Despite being a PHP package, it is a Symfony bundle, not a Laravel package. If the product in question is Laravel, this is a non-starter and should be recorded as such before anyone spends a sprint evaluating it. If we run Symfony services, it stays on the table.
• Roadmap de-risking for auth-adjacent features. SSO, RBAC, tenant/org membership, impersonation, and audit trails all sit on the identity layer. If gdbots/iam already models those, this bundle is the shortest path to shipping them in a Symfony service — which affects sequencing, not just implementation.
• Ecosystem and dependency-surface commitment. Adopting it is a vote for the gdbots ecosystem plus Auth0's SDK plus a hard-pinned Guzzle. Three transitive commitments in one line of composer.json. That belongs in an ADR, not buried in a diff.
• Breaking-change cadence is now a tracked risk. v5.1.0 ships under a POSSIBLE BREAKING CHANGES banner and forces auth0/auth0-php 9.x. Major SDK bumps in a security-critical path mean coordinated upgrades, regression testing of the login flow, and a re-review of token handling — a recurring cost, not a one-time integration cost.
• Risk sizing for the portfolio. Zero stars, zero dependents, single-vendor maintenance, but recent releases (v5.1.0, Jan 2026). The signal remains "alive but unproven," now with the added wrinkle that maintenance churn lands in a dependency we don't control.
• Cost avoidance framing. Apache-2.0 with no license fee; the savings are engineering weeks of security wiring plus the review surface of bespoke auth code — net of the upgrade tax implied by v5.1.x.

When to Consider This Package

Consider it when:

• You are on Symfony (6.x/7.x) and already use — or have seriously committed to — gdbots/iam-php.
• You are on Auth0, or have chosen it. Post-v5.1.0 this is close to a prerequisite: the bundle now tracks the Auth0 PHP SDK, not a generic OIDC abstraction.
• You are already on, or can cleanly move to, auth0/auth0-php 9.x. Staying on 8.x is no longer a supported path.
• You can live with a hard-coded Guzzle dependency. The maintainers deliberately disabled PSR-17 auto-discovery for security reasons, so the package references Guzzle concretely. Verify it co-exists with whatever Guzzle major your app and other SDKs already pull in — this is a real conflict vector in a mature Symfony app.
• You would otherwise write the Symfony security glue yourself (user providers, authenticators, firewalls, role voters) against a gdbots-backed identity store.
• You are a small team optimizing for time-to-first-auth over ecosystem breadth, and you can absorb a low-adoption dependency behind your own interface.
• You control both ends of the integration (internal services, pinned Symfony/Auth0/Guzzle versions), so version drift and API churn are manageable.

Look elsewhere when:

• Your stack is Laravel. Use native auth plus Sanctum/Passport and Fortify/Breeze/Jetstream, with auth0/login or Socialite if Auth0 is required directly. Adopting a Symfony bundle here is a category error — and v5.1.0 does not change that.
• Your IdP isn't Auth0. Keycloak, Cognito, Okta, Entra, WorkOS, or a homegrown OIDC provider puts you outside this package's center of gravity; Symfony's native OIDC support or knpu/oauth2-client is a better fit.
• You need SAML, social login breadth, or multi-IdP routing — this is single-IdP integration code, not an identity broker.
• You need a hosted IdP with an SLA rather than integration code you own.
• Your Guzzle/HTTP-client stack is pinned and immovable, or you rely on PSR-18/PSR-17 discovery for other integrations — the hard reference is a friction point worth costing before adoption.
• You need community depth, prompt security advisories, or a support contract — zero dependents means no external validation and no crowd-sourced bug surface, and a breaking auth SDK bump is exactly when you'd want both.
• You have no existing gdbots footprint: the cost of adopting the ecosystem plus Auth0 plus Guzzle will exceed the wiring it saves.

How to Pitch It (Stakeholders)

• Executives: an Apache-2.0, no-license-cost Symfony bundle that provides the security plumbing for a gdbots identity model backed by Auth0. It is not an identity provider and not a Laravel package. The value is "skip a few weeks of auth wiring in a Symfony service already on gdbots and Auth0," not "replace our auth strategy." v5.1.0 confirms the project is maintained but also confirms it moves with Auth0's SDK — expect periodic upgrade work.
• Engineering: standard Symfony security integration — providers, authenticators, access control — plus Auth0 SDK calls, which means less bespoke security code to write and review. v5.1.0 is a POSSIBLE BREAKING CHANGES release: it requires auth0/auth0-php 9.x and now hard-references Guzzle because PSR-17 auto-discovery was disabled for security. Budget a coordinated upgrade, check Guzzle major-version alignment against the rest of the app, re-test the full login/callback/refresh path, and keep it wrapped behind our own interface with pinned versions and an exit path.
• Security/compliance: permissive license and auditable source, and the Guzzle pin is a defensible security posture choice (no implicit PSR-17 client discovery). But adoption does not transfer our obligations — token handling, session policy, credential storage, Auth0 tenant configuration, and logging still need our own review and evidence. A security-critical dependency moving major SDK versions warrants re-review at each bump, not just at adoption.
• Recommendation: run a 1–2 week spike in one Symfony service, gated on the gdbots dependency being acceptable and on Auth0 being the chosen IdP. Target auth0/auth0-php 9.x from day one; do not attempt a mixed 8.x/9.x estate. Do not standardize org-wide on current evidence, and do not evaluate it for the Laravel product line at all.