Fortify Laravel Package

Product Decisions This Supports

• Admin-panel auth roadmap: ship vs. defer MFA this quarter. orchid/fortify is the reference wiring between Laravel Fortify's headless authentication backend and Orchid Platform's admin screens. Used correctly, it converts an open-ended question — "how much work is TOTP 2FA, verified email, password confirmation, and throttled login on the admin panel?" — into a scoped estimate you can put a date against. That estimate is the deliverable, not the package.

• Build vs. buy vs. copy vs. defer. This is a template, not a vendor choice. The decision it informs is "do we hand-roll Fortify screens in Orchid's Screen/Layout idiom, or start from the maintainer's known-good reference and adapt it?" It is a scoping input, not a procurement line item.

• Security questionnaire and compliance commitments. If SOC 2 / ISO 27001 access-control obligations are on the roadmap, the gap analysis between "Orchid native auth today" and "Fortify-equivalent auth" (TOTP 2FA with recovery codes, verified-email gates, password confirmation, throttled login) is precisely the artifact this template helps you size and defend in a review.

• Platform standardization. Organizations running multiple Laravel apps often standardize on "first-party apps authenticate through Fortify actions." The Orchid admin panel is the awkward exception; this template is the plausible migration path for that app class, and the decision is whether to bring it into the standard or formally exempt it.

• Use cases it realistically unlocks: internal admin panels for ops, finance, and support teams where MFA is driven by customer or auditor requirements, and where the team wants Fortify's headless actions rather than a bespoke auth implementation.

• Explicitly not supported: SSO. Fortify does not do SAML, OIDC, or social login. If enterprise SSO is a roadmap item, decision-making belongs at a different layer (Socialite, an OIDC client, or a hosted IdP) and must be sized separately. Do not let this package appear to solve it.

• Effort calibration for the sprint. Adoption replaces roughly two to three days of screen-building with a permanent, small ownership obligation. That framing is what turns "should we do 2FA?" from a debate into a capacity conversation.

When to Consider This Package

Consider it when:

• You are already committed to Orchid Platform and want Fortify's feature set — TOTP 2FA with recovery codes, email verification, password confirmation, rate limiting — without inventing the screen wiring yourself.
• You need a spike or estimate input. Clone it, read it, quantify the work, then decide. The cost is hours, not sprints.
• You want to see how Orchid's Screen/layout system maps onto Fortify's headless views before committing the team to that pattern.
• Your team is prepared to own the code after adoption. Treat it as a starting commit, not a composer require you track upstream — the project is distributed as a template precisely because you are expected to fork the pieces you need.
• You need a concrete artifact to support a compliance or security-review conversation about admin access controls — a readable implementation of throttled login, 2FA challenge, and recovery-code handling that a reviewer can trace.
• You are sequencing the work rather than porting it wholesale. The adoption path is incremental — login and logout first, then password reset, then email verification, then 2FA — so value can be demonstrated per milestone.

Look elsewhere when:

• Your pinned Orchid version already covers the requirement. Orchid's built-in auth has been closing the gap, notably around two-factor. Validate against the exact version you run before funding anything; if the answer is yes, the business case collapses to zero and that is a good outcome.
• You need a supported, maintained dependency. Zero stars, zero dependents, no visible CI, no test suite, no community triage — on the authentication boundary, the most security-sensitive surface in the product. Research input, not a commitment.
• You need SSO. Wrong layer entirely; see above.
• You are not on Orchid. All the value is the Orchid-specific glue.
• You need a reviewed supply chain or audit trail. An unaudited, low-traffic template is a code-review burden before it is an asset. Budget the review time or do not adopt.
• Your team cannot absorb permanent ownership of auth code. Without at least two engineers able to trace the auth flow end to end, this trade is not favorable.

How to Pitch It (Stakeholders)

For executives: This is a low-cost feasibility input, not a purchasing decision. It is a template published by the Orchid maintainer showing how to wire Laravel Fortify's authentication backend — password reset, email verification, two-factor authentication, login throttling — into the Orchid admin panel's UI. Its value to us is that it collapses an open-ended "how long would MFA take?" question into a few days of reading and a defensible estimate. It carries no license cost, no lock-in, and no vendor relationship. The trade is that we would copy the code and own it, so the real cost is a permanent, small maintenance obligation on our most security-sensitive surface. Recommendation: fund a short spike, produce the estimate, and make the ship/defer call with real numbers.

For engineering: Treat this as a reference implementation, not a dependency — do not composer require it. Clone it, read the service provider first (that file is the entire integration; everything else is presentation), then the routes, then the Screen subclasses. Before you invest anything, verify it against our pinned Orchid version, because the Screen/Layout APIs have moved across majors and templates characteristically lag. The four things that will bite us are: route collisions between Fortify's /login and the panel's /admin/*; guard mismatches between config/fortify.php and config/platform.php; a verified gate with no Orchid-hosted verification route, which locks users out permanently; and 2FA lockout without surfaced recovery codes or an admin-side reset. Decide on one authoritative auth stack before the first commit — running Fortify alongside Orchid's native auth produces divergent password-reset behaviour and intermittent guard bugs that are miserable to reproduce. There are no upstream tests and no triage, so the test coverage on the auth boundary is ours to write; at minimum, cover throttled login, a successful 2FA challenge, recovery-code consumption, and password-reset token expiry. Two engineers must be able to trace login → 2FA → session end to end before we ship.