Totp Bundle Laravel Package

Technical Evaluation

Architecture fit The first thing a TPM should surface in review is a naming and framing mismatch: svc/totp-bundle is a Symfony bundle, not a Laravel package, and it sits on top of scheb/2fa-bundle — a Symfony 2FA core. It contributes a presentation layer (Twig templates, enrollment/confirmation screens, form types, QR provisioning display), not the security engine. That shapes the product decision: the engine (Scheb) is mature and credible; the UI wrapper is unproven. Treat them as two separate buy/build calls. For a Laravel-first estate the artifact is not installable in an idiomatic way; for a Symfony shop already on Scheb, it is a near drop-in starter kit. Architecturally it is swappable and non-critical — which is good (low lock-in, MIT) and bad (it carries none of the security guarantees itself, so the security review lands on you either way).

Integration feasibility

• Symfony + Scheb already wired into a firewall + Twig available: hours to a day. Ordering is mandatory — core bundle installed, configured, routes/templates published, then this UI is meaningful.
• Laravel: not a conventional install. Different container, service providers vs. bundle registration, Blade vs. Twig, different auth guard model. Getting it running means porting it, at which point it is no longer this package. The honest Laravel answer is Fortify (ships TOTP + recovery codes) or pragmarx/google2fa plus a small Blade UI.
• Effort framing for planning: Symfony target = integration task; Laravel target = UI build task wearing a package costume.

Technical risk

• Adoption risk dominates, not code quality. 3 stars, 0 dependents, composite score 0.015, single maintainer, no visible CI matrix or security disclosure path. For a surface that touches secrets and the authentication flow, that is the material concern — not a style issue.
• Supply chain: the strongest part of the tree is the transitive scheb/2fa-bundle. The thin wrapper is the weak link. Vendor/fork under MIT and pin a commit.
• Drift risk: a low-activity UI package will lag Symfony major-version churn in container, Form, and Twig APIs — historically the exact place these wrappers break.
• Security surface to own regardless of choice: CSRF on enrollment, secret/QR leakage into logs and telemetry, secure backup-code generation/hashing, rate limiting and replay on verification, admin-side reset and audit.

Key questions

• Is there an actual Symfony service in the estate, or is "Laravel/PHP package" an indexing artifact? This gates the entire recommendation.
• Which Symfony and Scheb 2FA major versions are tested? Is there any CI?
• Who maintains it, and is there a security contact or disclosure process?
• Do the parent bundle's shipped templates already satisfy the requirement — making this wrapper redundant?
• What is the compliance driver (SOC 2, ISO 27001, enterprise security questionnaires)? If controls are in scope, provenance and patch SLAs outweigh UI convenience.
• Is the real roadmap gap TOTP enrollment, or passkeys/WebAuthn? This package does not address the latter and should not be scoped as if it does.

Integration Approach

Stack fit

• Symfony + Twig + Scheb 2FA: natural fit, minimal glue, low ceremony. Best and arguably only sensible target.
• Laravel + Blade + Fortify / pragmarx/google2fa: poor fit. Fortify covers the same ground with a maintained upstream; compare total integration cost before choosing the bundle.
• Mixed estate: use as a design reference for enrollment UX and backup-code flow, not as a runtime dependency.

Migration path

• Greenfield Laravel: do not adopt. Use Fortify's two-factor feature; if a custom enrollment experience is required, build a handful of screens against Fortify's contracts (days, not weeks) and own the patch surface.
• Existing Symfony app on Scheb: spike behind a feature flag in non-production, validate template override and route precedence against the parent bundle, then promote per environment.
• Existing Laravel app with homegrown TOTP: mine this package's enrollment and backup-code UX patterns; skip the dependency.
• If a team insists on reuse: fork/vendor the UI layer, pin the Scheb core, and accept ownership — viable only where the Symfony path is genuinely real.

Compatibility

• Confirm PHP floor, Symfony 5.4/6.x/7.x support, and alignment with the Scheb 2FA major version (a wrapper assuming older Form/Twig APIs will break on current Symfony).
• Verify interaction with the parent bundle's route prefix and firewall config — overlapping routes are a common failure mode.
• Check locale/translation assets and template overrides for unintended shadowing of parent templates.

Sequencing

1. Resolve the framework question first; it gates everything downstream.
2. If Symfony: install and configure scheb/2fa-bundle and prove end-to-end TOTP enrollment on default templates.
3. Then layer this UI and compare against defaults. If defaults suffice, stop — do not take the dependency.
4. Independent security review of the enrollment flow (secret handling, QR provisioning, rate limiting, replay, recovery codes) regardless of package choice.
5. Roll out behind a flag with a documented kill switch back to parent-bundle defaults.

Operational Impact

Maintenance Low direct cost (thin surface, small code volume, MIT) but high ownership cost if upstream stalls — you become de facto maintainer of an authentication-path UI. Budget recurring Symfony/Scheb upgrade validation and template re-verification, and assume no upstream assistance.

Support Community-only and effectively absent given adoption: no SLA, no commercial backing, sparse issue history to learn from. An internal runbook is mandatory before rollout. Assume informal security disclosure; track scheb/2fa-bundle advisories directly, since real vulnerabilities will land there, and treat this package as replaceable middleware.

Scaling Not a throughput concern — enrollment is low-QPS, per-user, one-time; there is no meaningful horizontal scaling risk. The real scaling question is organizational: across many apps, one internally owned 2FA enrollment component beats N copies of an unmaintained wrapper.

Failure modes

• Silent route/template shadowing after a parent-bundle upgrade — broken or bypassed enrollment screens.
• Framework major upgrade strands the wrapper, breaking auth at the worst moment.
• Abandonment without a fork — unpatched UI accumulating in the authentication path.
• Parent firewall misconfiguration — the 2FA prompt skipped entirely; a security-control failure, not an availability one.
• QR/secret provisioning defects — user lockout, or secrets leaking into logs (test log redaction explicitly).
• Mitigations throughout: pin versions, feature-flag the UI, keep parent-bundle default templates as a documented fallback, subscribe to core-library advisories.

Ramp-up

• Symfony team: near zero — standard bundle install, Twig familiarity, config publish; roughly half a day including review.
• Laravel team: deceptively low at first glance, high in practice, because the cost is a port rather than a learning curve. Plan for the effort of building the UI, not adopting the package.
• Documentation and examples are thin; expect to read the parent bundle's docs and this package's source instead of any guide.

TPM bottom line: Frame this to stakeholders as a reference implementation to fork and own, not a vendor dependency — a sprint-shortcut for TOTP enrollment screens on a Symfony codebase, contingent on the framework question resolving in its favor. On Laravel, the recommendation is Fortify, and the only durable value here is the UX pattern.