Forgot Password Bundle Laravel Package

Product Decisions This Supports

• Feature delivery: account recovery for API-first products. This bundle implements the "forgot password" flow — request reset → issue token → verify token → set new password — exposed as REST endpoints rather than server-rendered forms. That maps directly to the recovery flow in mobile apps, SPAs, and third-party API consumers, where there is no session or HTML form to fall back on.
• Build vs. buy on a security-sensitive commodity feature. Password reset is table stakes but easy to get subtly wrong (token entropy, single-use enforcement, expiry, enumeration leaks, timing attacks). Adopting a focused, MIT-licensed implementation trades a small integration cost for a vetted token lifecycle instead of a from-scratch build.
• Roadmap sequencing. Because it is a single-purpose bundle, it can be scoped as a discrete, low-risk work item in a release rather than a multi-sprint auth initiative. It de-risks the "unblocks self-service account recovery" item without committing the team to a broader identity platform.
• Framework-fit gate. Important: despite the "Laravel/PHP" framing, this is a Symfony bundle (coopTilleuls), not a Laravel package. If the product is Laravel, this is not a drop-in — it is at best a reference implementation for the token flow. Confirm the stack before this enters a roadmap.
• Use cases that fit well: token-based reset for JSON APIs, headless/decoupled frontends, internal services needing standardized recovery endpoints, and teams that already own their mail/notification infrastructure and only need the token mechanics.
• Decision it does not support: it is not an identity provider, not MFA, not SSO, and not a user-facing email system. Treat it as one bounded component, not an auth platform decision.

When to Consider This Package

Consider it when:

• The application is Symfony (the bundle targets Symfony's HTTP kernel, DI, and routing), and the API is REST/JSON rather than form-based.
• You want the reset token lifecycle handled — generation, persistence, expiry, single-use validation — while retaining ownership of user lookup, email delivery, and password hashing.
• You need something small and auditable. The surface area is narrow, which is a genuine advantage for a security-touching feature.
• MIT licensing and no per-seat cost matter for budget or redistribution constraints.
• You are willing to pin a version, read the source, and own the integration — the project is small enough that you should expect to be your own support.

Look elsewhere when:

• The stack is Laravel. Use Laravel's built-in password broker and Password::sendResetLink / Password::reset — it is first-party, maintained, and already wired to notifications. This bundle would be a porting exercise with none of the upside.
• Ecosystem maturity is a hard requirement. 85 stars and 0 dependents is a genuine adoption signal: almost no one in the wild depends on this, so battle-testing, community answers, and third-party security review are thin. For a customer-facing auth flow at scale, that is a real risk to price in.
• You need more than password reset — MFA, magic links, email verification, rate limiting, audit logging. Buying a narrow tool and then surrounding it with custom code often costs more than a broader auth solution.
• You need turnkey email templating, localization, or branded flows. This bundle deliberately stops short of that; if your team does not already have a transactional email pipeline, the "small" integration grows.
• Governance requires a named maintainer, SLA, or security disclosure process. Verify the project's current release cadence and advisory history before committing; the "last release" date alone is not a substitute for a support commitment.

How to Pitch It (Stakeholders)

For executives: This is a small, free, open-source component that implements the password-reset flow for an API-based product — the "I forgot my password" journey that customers expect and that currently blocks self-service account recovery in our backlog. It is MIT-licensed, so there is no purchase cost or vendor lock-in, and it is narrow enough that adopting it is a contained engineering task rather than a platform bet. The trade-off to acknowledge is maturity: it is a focused, low-adoption project, so we get simplicity and auditability but not a large community or a commercial support contract. Recommended posture: adopt only if we are on Symfony, budget a short security review, and treat the token lifecycle as the part we are buying and the email delivery as the part we already own.

For engineering: It is a Symfony bundle that provides the REST endpoints and token lifecycle for password reset, leaving user resolution, mail sending, and password encoding to our existing services. Integration is a config block, an entity mapping, and wiring our mailer into the request event — days, not weeks. Two conditions before we proceed: (1) confirm we are on Symfony, because this does not port to Laravel and Laravel already ships an equivalent; (2) review the token generation, expiry, and single-use logic against our security bar, since with 0 known dependents we are effectively the first serious adopter. Pin the version, vendor the source, and write our own integration tests around token replay and user enumeration.

Bottom line: a good fit and a cheap win on Symfony; the wrong tool on Laravel. Decide on framework fit first, maturity risk second.