Otp Auth Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on authentication plumbing: this package provides OTP (one-time-passcode) enrollment and a recoveryAction for account recovery. Buying it removes a security-sensitive, low-differentiation build from your roadmap — the kind of code that is cheap to write once and expensive to maintain correctly.
• Roadmap: self-serve account recovery. The 1.2.4 hotfix defines an explicit contract — recoveryAction now throws an exception when the user has no OTP authentication configured, instead of proceeding. That is a product decision the package has made for you: recovery is only valid for users who are actually enrolled. Your roadmap must account for the pre-enrollment / migrated-user segment separately (support-assisted recovery, re-enrollment prompt, or a different flow).
• UX and error-contract decisions: the package now signals an invalid recovery attempt via exception. That is a backend concern that surfaces as a product concern — what does the user see when they hit "recover" without OTP set up? That copy, redirect, and support-path is yours to own; the package will not silently no-op for you.
• Compliance and security posture: 2FA + recovery is a recurring line item in SOC 2, ISO 27001, and enterprise security questionnaires. Adopting a maintained package lets you answer "how is OTP recovery handled?" with a versioned dependency rather than an internal design doc.
• Use cases to prioritize: B2B SaaS with admin panels, step-up auth before sensitive actions (payouts, key rotation, data export), and any product where account lockout is a churn risk.

When to Consider This Package

Consider it when:

• You are on Laravel/PHP and need OTP-based second factor plus a recovery path, without building and auditing the crypto and flow logic yourself.
• Your team is small and would rather inherit a maintained implementation than own a security-sensitive surface.
• Your recovery flows are only ever offered to already-enrolled users — which is precisely the assumption 1.2.4 encodes.

Before adopting, verify:

• Exception handling is mandatory. Any controller or job calling recoveryAction must catch the new exception and map it to a user-facing 4xx (not a 500). Audit existing call sites; grep for recoveryAction and add a regression test for the "user without OTP" case. Pin to ^1.2.4 so you don't ship the pre-hotfix silent-failure behavior.
• The exception's type and message. Confirm it is a dedicated, catchable exception class rather than a generic \Exception; catching broadly is a code smell that will bite you later.
• Whether the throwing behavior matches your API contract. If your API returns structured error codes, you need a translation layer.

Look elsewhere when:

• You need WebAuthn/passkeys, hardware tokens, or federated enterprise SSO — this is OTP-shaped, not a full IAM platform.
• You need recovery to work for users without OTP (this hotfix explicitly rejects that), or you need a soft-fail UX rather than exceptions.
• You require vendor SLAs, paid support, or a formal security review with a commercial counterparty.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost dependency that covers two-factor authentication and account recovery — a security-sensitive area we would otherwise staff and maintain ourselves. Release 1.2.4 is a one-line hardening patch: recovery attempts for users who never set up OTP now fail loudly instead of proceeding silently. That is a net reduction in risk (silent failures in auth flows are exactly the bugs that become incidents and support escalations), there is no migration work, and no customer-visible change for correctly enrolled users.

For engineering: Behavior change is confined to recoveryAction, which now throws when the target user has no OTP authentication configured. Action items: (1) wrap all recoveryAction call sites in a try/catch and return a clear 4xx with re-enrollment guidance; (2) add a test covering the no-OTP user; (3) pin ^1.2.4 and bump the lockfile. No API removal, no schema change, no deprecations — but treat the new exception as part of the public contract going forward and don't let it escape as an unhandled 500.